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
Copy file name to clipboardExpand all lines: references/pre-aggregates/getting-started.mdx
+66Lines changed: 66 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,6 +71,7 @@ Pre-aggregates are defined under the `pre_aggregates` key in your model configur
71
71
| `granularity` | No | Time granularity for the `time_dimension`. Valid values: `hour`, `day`, `week`, `month`, `quarter`, `year`. Must be paired with `time_dimension`. |
72
72
| `max_rows` | No | Maximum number of rows to store in the materialization. If the aggregation exceeds this limit, the result is truncated. Must be a positive integer. |
73
73
| `refresh` | No | Schedule configuration for automatic re-materialization. See [Scheduling refreshes](#scheduling-refreshes). |
74
+
| `materialization_role` | No | Fixed user attributes to use when materializing the pre-aggregate. See [Materialization role](#materialization-role). |
74
75
75
76
<Note>
76
77
If you specify `time_dimension`, you **must** also specify `granularity`, and vice versa.
@@ -143,6 +144,71 @@ You can set `max_rows` to cap the size of a materialization. If the aggregation
143
144
When `max_rows` is applied, some data is excluded from the materialization. Queries that match the pre-aggregate may return incomplete results. Use this setting carefully and monitor for the "max rows applied" warning in the [monitoring UI](/references/pre-aggregates/monitoring).
144
145
</Warning>
145
146
147
+
## Materialization role
148
+
149
+
If your model uses user attributes in SQL, the user who triggers the materialization can affect what gets stored in the pre-aggregate.
150
+
151
+
For example, if the model has `sql_filter: "customers.region IN (${ld.attr.allowed_regions})"`, the materialized table will only contain the regions that the admin who triggered the materialization happens to have access to. If that admin has `allowed_regions: ["EMEA"]`, the pre-aggregate will only contain EMEA rows.
152
+
153
+
Use `materialization_role` to define a fixed set of user attributes for materializing the pre-aggregate. At query time, Lightdash ignores `materialization_role` and uses the real viewer user's attributes instead, so a user with `allowed_regions: ["EMEA"]` still only sees EMEA rows.
sql_filter: "customers.region IN (${ld.attr.allowed_regions})"
192
+
pre_aggregates:
193
+
- name: orders_daily_by_region
194
+
dimensions:
195
+
- customers.region
196
+
metrics:
197
+
- total_order_amount
198
+
time_dimension: order_date
199
+
granularity: day
200
+
materialization_role:
201
+
email: materialize@acme.com
202
+
attributes:
203
+
allowed_regions:
204
+
- EMEA
205
+
- APAC
206
+
- NA
207
+
```
208
+
</Tab>
209
+
</Tabs>
210
+
211
+
With this setup, the materialized table always contains EMEA, APAC, and NA rows regardless of who triggered the materialization. When a viewer queries the pre-aggregate, Lightdash applies their own user attributes to the query, not the `materialization_role`.
0 commit comments