You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Update passing-dynamic-parameters-in-a-query.mdx
FILTER_PARAMS should always be used in this use case to avoid a massive cross join. I also added a simpler code snippet that is easier to adapt to any use case rather than the original verbose version.
* Update passing-dynamic-parameters-in-a-query.mdx
Fix missing quote
Copy file name to clipboardExpand all lines: docs/pages/guides/recipes/data-modeling/passing-dynamic-parameters-in-a-query.mdx
+58-12Lines changed: 58 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,12 +16,17 @@ filter. The trick is to get the value of the city from the user and use it in
16
16
the calculation. In the recipe below, we can learn how to join the data table
17
17
with itself and reshape the dataset!
18
18
19
+
<WarningBox>
20
+
21
+
This pattern only allows users to choose from values that already exist in the data set. Rather than injecting arbitrary user input into the query, this method involves filtering the data based on the user's input and utilizing a single value result in a calculation.
22
+
23
+
</WarningBox>
24
+
19
25
## Data modeling
20
26
21
-
Essentially what we will be doing is cross joining all city values with the rows in the data table.
22
-
This will duplicate each row for every city in the dataset. Then, we will require the user
23
-
to choose a city to filter on, and this will bring us back to our original number of rows. What this
24
-
gives us is a new column in the dataset with the value that the user chose, which we can reference in our metrics.
27
+
Essentially what we will be doing is allowing the user to select a specific city value, then cross joining that value with the rows in the data table.
28
+
This will maintain the orginal number of rows in the dataset while adding a new column that has the value that the user chose.
29
+
This will allow us to use that value in our calculations.
25
30
In this case, we will use that value to filter a single metric so that we can compare that metric with the whole population.
26
31
27
32
Let's explore the `users` cube data that contains various information about
@@ -35,13 +40,16 @@ users, including city and gender:
35
40
| ... | ... | ... | ... |
36
41
37
42
To calculate the ratio between the number of women in a particular city and the
38
-
total number of people in the country, we need to define three measures. One of
39
-
them can receive the city value from the filter in a query. Cube will apply this
40
-
filter via the `WHERE` clause to the dataset. So, we need to reshape the dataset
41
-
so that applying this filter wouldn’t affect the calculations. In this use case,
42
-
we can join the data table with itself to multiply the `city` column — applying
43
-
the filter would remove the multiplication while still allowing to access the
44
-
filter value:
43
+
total number of people in the country, we need to define three measures, one of
44
+
which uses the city value that the user chose.
45
+
46
+
In order to prevent filtering the whole dataset with the user-selected value,
47
+
we will need to define a new dimension that, when filtered on, only filters a specific part of the query.
48
+
We will use this new filter field along with the [`FILTER_PARAMS`][ref-filter-params]
49
+
parameter in the sql of the cube. This will allow us to apply to the filter to a subquery
50
+
rather than the whole query so that it doesn't affect other calculations.
51
+
In this use case, we can join the data table with itself to create a new city_filter
52
+
column with a single value that the user chose so that we can use it in other calculations.
0 commit comments