diff --git a/api-reference/v1/recipes.mdx b/api-reference/v1/recipes.mdx index ef3b9ec4..0e0f5c84 100644 --- a/api-reference/v1/recipes.mdx +++ b/api-reference/v1/recipes.mdx @@ -35,7 +35,7 @@ Use a recipe when: You will need: - Python 3.9+ installed -- A [Personal Access Token (PAT)](/personal-settings/create-personal-tokens#personal-access-tokens) +- A [Personal Access Token (PAT)](/personal-settings/create-personal-tokens) - Your Lightdash instance URL - The project UUID you want to modify diff --git a/explore/create-custom-fields.mdx b/explore/create-custom-fields.mdx index 0c2e92ab..986ee987 100644 --- a/explore/create-custom-fields.mdx +++ b/explore/create-custom-fields.mdx @@ -130,7 +130,7 @@ Custom SQL dimensions let you pull in new data directly from your database, whic **Security note:** -Custom SQL dimensions can query any data from your warehouse, so they should only be created by trusted users (admins and developers). For most cases, it's safer and more reusable to define dimensions in your dbt files. If you want to make a custom SQL dimension reusable, use the [dbt write-back](/integrations/dbt/write-back#dbt-write-back) feature to move it into your dbt project. +Custom SQL dimensions can query any data from your warehouse, so they should only be created by trusted users (admins and developers). For most cases, it's safer and more reusable to define dimensions in your dbt files. If you want to make a custom SQL dimension reusable, use the [dbt write-back](/integrations/dbt/write-back#write-back-dimensions-from-custom-dimensions) feature to move it into your dbt project. diff --git a/explore/sql-runner.mdx b/explore/sql-runner.mdx index 5eb43dcd..d02183da 100644 --- a/explore/sql-runner.mdx +++ b/explore/sql-runner.mdx @@ -41,7 +41,7 @@ You can access your **Query history** from your session by clicking on the `SQL Once you've run your query, you can either: -1. [**Build and save a Chart**](#building-charts-in-the-sql-runner) +1. [**Build and save a Chart**](#saved-charts-in-the-sql-runner) 2. [**Create a Virtual View so your query becomes a reusable table in Lightdash**](/semantic-layer/virtual-views) 3. [**Write-back to dbt so your query is saved as a governed model.**](/integrations/dbt/write-back) 4. Click the link icon in the top-right to share your query draft with a coworker (or save it yourself to return to later). diff --git a/get-started/quickstart/connect-project.mdx b/get-started/quickstart/connect-project.mdx index 7ccd7c76..d67da9cd 100644 --- a/get-started/quickstart/connect-project.mdx +++ b/get-started/quickstart/connect-project.mdx @@ -43,6 +43,8 @@ We always recommend giving read-only permissions to Lightdash, that way you ensu Combine this with **Connect via Lightdash CLI (SSO)** on Snowflake or **Sign in with Google** on BigQuery (see below) to create a project without ever pasting a credential — the same feature flag also enables smart defaults (recommended project, largest dataset/database, recommended warehouse) after you authenticate. + + Since we host your Lightdash for you, you may need to add our static IP addresses to the allow-list for your security group or firewall rules so they don’t block calls from your Lightdash Cloud to your connected databases. diff --git a/self-host/customize-deployment/environment-variables.mdx b/self-host/customize-deployment/environment-variables.mdx index 8d5381e5..a042ad5a 100644 --- a/self-host/customize-deployment/environment-variables.mdx +++ b/self-host/customize-deployment/environment-variables.mdx @@ -750,7 +750,7 @@ On server start, we will check the following variables, and update some configur ## Initialize multiple projects -Set `LD_SETUP_PROJECTS` to a JSON array to provision **multiple projects at once**. This is a drop-in replacement for the single-project `LD_SETUP_PROJECT_*` variables described in [Initialize instance](#initialize-instance) — when `LD_SETUP_PROJECTS` is set, the legacy `LD_SETUP_PROJECT_*` and `LD_SETUP_GITHUB_*` variables are ignored. +Set `LD_SETUP_PROJECTS` to a JSON array to provision **multiple projects at once**. This is a drop-in replacement for the single-project `LD_SETUP_PROJECT_*` variables described in [Initialize instance](#initialize-instance-enterprise) — when `LD_SETUP_PROJECTS` is set, the legacy `LD_SETUP_PROJECT_*` and `LD_SETUP_GITHUB_*` variables are ignored. On every boot, Lightdash matches each entry to an existing project by its `name`: new names are created, existing names are updated in place. @@ -762,7 +762,7 @@ Multi-project setup supports Databricks project types and GitHub dbt configurati ### Required companion variables -The admin, organization, and API key variables from [Initialize instance](#initialize-instance) still apply. `LD_SETUP_ADMIN_EMAIL` is required — without it, `LD_SETUP_PROJECTS` is ignored. +The admin, organization, and API key variables from [Initialize instance](#initialize-instance-enterprise) still apply. `LD_SETUP_ADMIN_EMAIL` is required — without it, `LD_SETUP_PROJECTS` is ignored. ### Schema diff --git a/semantic-layer/dimensions.mdx b/semantic-layer/dimensions.mdx index 530de677..b544e989 100644 --- a/semantic-layer/dimensions.mdx +++ b/semantic-layer/dimensions.mdx @@ -25,7 +25,7 @@ models: Write these entries by hand, or generate one for every column in a model with [`lightdash generate`](/workflow/cli/generate). - Dimensions cannot use window functions in their `sql`. A dimension's SQL is inserted into the same `SELECT` as the main `GROUP BY` in the generated query, and SQL does not allow window functions in that position. If you need window-function logic, either model it directly in your dbt model (so the value is precomputed before Lightdash queries it), or add a [table calculation](/explore/table-calculations) on the query results. Lightdash also supports a small set of built-in window operations through [post calculation metrics](/semantic-layer/metrics#post-calculation-metrics) (`percent_of_previous`, `percent_of_total`, `running_total`). + Dimensions cannot use window functions in their `sql`. A dimension's SQL is inserted into the same `SELECT` as the main `GROUP BY` in the generated query, and SQL does not allow window functions in that position. If you need window-function logic, either model it directly in your dbt model (so the value is precomputed before Lightdash queries it), or add a [table calculation](/explore/table-calculations) on the query results. Lightdash also supports a small set of built-in window operations through [post calculation metrics](/semantic-layer/metrics#post-calculation-metrics-experimental) (`percent_of_previous`, `percent_of_total`, `running_total`). diff --git a/semantic-layer/joins.mdx b/semantic-layer/joins.mdx index 5630c9c0..156f8560 100644 --- a/semantic-layer/joins.mdx +++ b/semantic-layer/joins.mdx @@ -928,7 +928,7 @@ FROM accounts **Option 2: Add a chained join to the other explore** -Explicitly add the missing table as a [chained join](#chained-join-example) on any explore that needs it. This makes the referenced fields available in that context. +Explicitly add the missing table as a chained join on any explore that needs it. This makes the referenced fields available in that context. ```yaml dbt v1.10+ diff --git a/semantic-layer/lightdash-config-yml.mdx b/semantic-layer/lightdash-config-yml.mdx index 8336b4b5..568d3b8c 100644 --- a/semantic-layer/lightdash-config-yml.mdx +++ b/semantic-layer/lightdash-config-yml.mdx @@ -220,7 +220,7 @@ PUT /api/v2/projects/{projectUuid}/defaults { "pre_aggregate_execution_fallback": false } ``` -This setting only covers **execution-time** failures on a matched query. Queries that don't match any pre-aggregate — including cases where the pre-aggregate can't be resolved, or when a `sql_filter` or non-field reference makes the query [ineligible](/semantic-layer/pre-aggregates#sql-filter-and-pre-aggregates) — still run against the warehouse. +This setting only covers **execution-time** failures on a matched query. Queries that don't match any pre-aggregate — including cases where the pre-aggregate can't be resolved, or when a `sql_filter` or non-field reference makes the query [ineligible](/semantic-layer/pre-aggregates#sql_filter-and-pre-aggregates) — still run against the warehouse. ### Case sensitivity hierarchy diff --git a/semantic-layer/metrics.mdx b/semantic-layer/metrics.mdx index 02a1d079..49fdb96a 100644 --- a/semantic-layer/metrics.mdx +++ b/semantic-layer/metrics.mdx @@ -143,7 +143,7 @@ Aggregate metric types perform (surprise, surprise) aggregations. Sums and avera Aggregate metrics can _only_ reference dimensions, not other metrics. -Aggregate metrics cannot use window functions in their `sql`. Their SQL is wrapped in an aggregate function and evaluated as part of the main `GROUP BY` in the generated query, and SQL does not allow window functions inside an aggregate call. See [post calculation metrics](#post-calculation-metrics) for the window operations Lightdash does support and what to do instead. +Aggregate metrics cannot use window functions in their `sql`. Their SQL is wrapped in an aggregate function and evaluated as part of the main `GROUP BY` in the generated query, and SQL does not allow window functions inside an aggregate call. See [post calculation metrics](#post-calculation-metrics-experimental) for the window operations Lightdash does support and what to do instead. ### Non-aggregate metrics @@ -151,7 +151,7 @@ Non-aggregate metrics are metric types that, you guessed it, do _not_ perform ag Numbers and booleans are examples of non-aggregate metrics. These metric types perform a calculation on a single data point, so they can only reference aggregate metrics. They _cannot_ reference dimensions. -Non-aggregate metrics cannot use window functions in their `sql`. Their SQL is inserted alongside the aggregate metrics in the same `SELECT`, which runs in the same step as the `GROUP BY`, so window functions — which must run after aggregation — are not allowed. See [post calculation metrics](#post-calculation-metrics) for the window operations Lightdash does support and what to do instead. +Non-aggregate metrics cannot use window functions in their `sql`. Their SQL is inserted alongside the aggregate metrics in the same `SELECT`, which runs in the same step as the `GROUP BY`, so window functions — which must run after aggregation — are not allowed. See [post calculation metrics](#post-calculation-metrics-experimental) for the window operations Lightdash does support and what to do instead. ### Post calculation metrics Experimental @@ -317,8 +317,8 @@ Here are all of the properties you can customize: | [number](#number) | Non-aggregate | For adding calculations to metrics that return numbers. | | [string](#string) | Non-aggregate | For metrics that contain letters or special characters | | [sum](#sum) | Aggregate | Generates a sum of values within a column | -| [sum_distinct](#sum_distinct) | Aggregate (Beta) | Generates a sum of values, deduplicating by specified keys | -| [average_distinct](#average_distinct) | Aggregate (Beta) | Generates an average of values, deduplicating by specified keys | +| [sum_distinct](#sum_distinct-beta) | Aggregate (Beta) | Generates a sum of values, deduplicating by specified keys | +| [average_distinct](#average_distinct-beta) | Aggregate (Beta) | Generates an average of values, deduplicating by specified keys | | [percent_of_previous](#percent_of_previous) | Post calculation (Experimental) | Current value as a percentage of the previous row's value | | [percent_of_total](#percent_of_total) | Post calculation (Experimental) | Current value as a percentage of the total across the result set (or partition) | | [running_total](#running_total) | Post calculation (Experimental) | Cumulative total | @@ -327,7 +327,7 @@ Here are all of the properties you can customize: Takes the percentile of the values in the given field. Like SQL's `PERCENTILE_CONT` function. -The `percentile` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. +The `percentile` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. For example, this creates a metric `median_price` by taking the 50% percentile of the `item_price` dimension: @@ -372,7 +372,7 @@ metrics: Takes the 50th percentile of the values in the given field. Like SQL's `PERCENTILE_CONT(0.5)` function. -The `median` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. +The `median` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. For example, this creates a metric `median_price` by taking the 50% percentile of the `item_price` dimension: @@ -414,7 +414,7 @@ metrics: Takes the average (mean) of the values in the given field. Like SQL's `AVG` function. -The `average` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. +The `average` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. For example, this creates a metric `avg_price` by taking the average of the `item_price` dimension: @@ -509,7 +509,7 @@ metrics: Does a table count, like SQL’s `COUNT` function. -The `count` metric can be used on any dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a set of values. +The `count` metric can be used on any dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a set of values. For example, this creates a metric `number_of_users` by counting the number of `user_id` values in the table: @@ -551,7 +551,7 @@ metrics: Counts the number of distinct values in a given field. It's like SQL’s `COUNT DISTINCT` function. -The `count_distinct` metric can be used on any dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a set of values. +The `count_distinct` metric can be used on any dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a set of values. For example, this creates a metric `number_of_unique_users` by counting the number of unique `user_id` values in the table: @@ -645,7 +645,7 @@ metrics: Max gives you the largest value in a given numeric field. It's like SQL’s `MAX` function. -The `max` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric value. +The `max` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric value. Because `type: max` metrics only work with numerical fields, you can't use them to find a maximum date. Instead, you can use the `MAX()` function in the `sql` parameter of a metric of `type: date` to get a maximum date (you can see an [example of this in the date section](#date). @@ -689,7 +689,7 @@ metrics: Min gives you the smallest value in a given numeric field. It's like SQL’s `MIN` function. -The `min` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric value. +The `min` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric value. Because `type: min` metrics only work with numerical fields, you can't use them to find a minimum date. Instead, you can use the `MIN()` function in the `sql` parameter of a metric of `type: date` to get a minimum date (you can see an [example of this in the date section](#date). @@ -801,7 +801,7 @@ The example above also uses the NULLIF() SQL function to avoid division-by-zero Adds up the values in a given field. Like SQL's `SUM` function. -The `sum` metric can be used on any numeric dimension or, [for custom SQL](#using-custom-SQL-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. +The `sum` metric can be used on any numeric dimension or, [for custom SQL](#custom-sql-in-aggregate-metrics), any valid SQL expression that gives a numeric table column. For example, this creates a metric `total_revenue` by adding up the values in the `revenue` dimension: @@ -1021,7 +1021,7 @@ If you want a per-group total that varies with an unrelated dimension, add that `average_distinct` is in [Beta](/support/feature-maturity-levels). -Calculates the average of values in a given field while deduplicating data based on one or more specified distinct keys. This works the same way as [`sum_distinct`](#sum_distinct), but computes an average instead of a sum. +Calculates the average of values in a given field while deduplicating data based on one or more specified distinct keys. This works the same way as [`sum_distinct`](#sum_distinct-beta), but computes an average instead of a sum. Lightdash already supports [SQL fanout protection](/semantic-layer/joins#handling-fanouts) to remove duplicates when joining tables together. `average_distinct` allows you to remove duplicates from wide tables where deduplication cannot be handled at the join level. @@ -1185,7 +1185,7 @@ metrics: ``` -`average_distinct` follows the same rules as `sum_distinct` for how selected dimensions interact with `distinct_keys`. See [How selected dimensions interact with `distinct_keys`](#sum_distinct) for details. +`average_distinct` follows the same rules as `sum_distinct` for how selected dimensions interact with `distinct_keys`. See [How selected dimensions interact with `distinct_keys`](#sum_distinct-beta) for details. ### string diff --git a/semantic-layer/pre-aggregates.mdx b/semantic-layer/pre-aggregates.mdx index 9eb15250..847e449e 100644 --- a/semantic-layer/pre-aggregates.mdx +++ b/semantic-layer/pre-aggregates.mdx @@ -157,7 +157,7 @@ When a user runs a query, Lightdash checks whether a pre-aggregate can serve it - **Fields are available** — every dimension, metric, and filter dimension in the query exists somewhere in the pre-aggregate. - **Grain is reachable** — if the query uses a time dimension, its granularity is **equal or coarser** than the pre-aggregate's, so the rows can be rolled up. Month is a coarser grain than day. Day is a coarser grain than hour. - **Scope is compatible** — if the pre-aggregate defines its own `filters`, the query includes an **equal or narrower** filter, so the subset can be filtered from the pre-aggregate base. -- **Metrics re-aggregate cleanly** — all metrics are [supported types](#supported-metric-types). Non-additive metrics like `count_distinct`, `median`, and `percentile` can't be faithfully re-computed from stored rows, so they only match on an [exact match](#exact-match-queries) of the pre-aggregate. Raw SQL table calculations and SQL that depends on [Parameters](/semantic-layer/parameters) are resolved at query time and are never eligible. Model [`sql_filter`](/semantic-layer/tables#sql-filter-row-level-security) is eligible as long as every field it references is a pre-aggregate dimension — see [`sql_filter` and pre-aggregates](#sql-filter-and-pre-aggregates). +- **Metrics re-aggregate cleanly** — all metrics are [supported types](#supported-metric-types). Non-additive metrics like `count_distinct`, `median`, and `percentile` can't be faithfully re-computed from stored rows, so they only match on an [exact match](#exact-match-queries) of the pre-aggregate. Raw SQL table calculations and SQL that depends on [Parameters](/semantic-layer/parameters) are resolved at query time and are never eligible. Model [`sql_filter`](/semantic-layer/tables#sql-filter-row-level-security) is eligible as long as every field it references is a pre-aggregate dimension — see [`sql_filter` and pre-aggregates](#sql_filter-and-pre-aggregates). A **day** pre-aggregate serves `day`, `week`, `month`, `quarter`, and `year` queries. A **month** pre-aggregate serves `month`, `quarter`, and `year` — but **not** `day` or `week`, since those need finer-grained data. @@ -509,7 +509,7 @@ Pre-aggregates do not support: - [Personal warehouse connections](/personal-settings/personal-warehouse-connections). Materialization always runs under a single user's credentials, so warehouse-level access rules are not applied per viewer. If you rely on personal warehouse connections to enforce data access, use [results caching](/semantic-layer/caching) instead. - [Parameters](/semantic-layer/parameters) — parameter values are picked at query time, so they cannot be resolved during materialization. Queries that use parameters fall back to the warehouse. -- [User attributes](/workspace-admin/user-attributes) referenced from a dimension or metric SQL expression. They're only resolved at serve time in [`sql_filter`](#sql-filter-and-pre-aggregates); [`required_attributes`](/semantic-layer/tables#required-attributes) and [`any_attributes`](/semantic-layer/tables#any-attributes) are supported through [`materialization_role`](/semantic-layer/pre-aggregates#materialization-role). +- [User attributes](/workspace-admin/user-attributes) referenced from a dimension or metric SQL expression. They're only resolved at serve time in [`sql_filter`](#sql_filter-and-pre-aggregates); [`required_attributes`](/semantic-layer/tables#required-attributes) and [`any_attributes`](/semantic-layer/tables#any-attributes) are supported through [`materialization_role`](/semantic-layer/pre-aggregates#materialization-role). - [Custom metrics](/explore/create-custom-fields#custom-metrics) created in the Explorer - [Custom SQL dimensions](/explore/create-custom-fields#custom-sql) created in the Explorer ([Custom bin dimensions](/explore/create-custom-fields#bin) are supported) - SQL table calculations ([Formula table calculations](/explore/table-calculations/formulas) are supported) @@ -697,6 +697,6 @@ These queries would **not** match and would query the warehouse directly: - Queries grouped by a dimension not in the pre-aggregate (for example, `customer_id`) - Queries with hourly granularity (finer than the pre-aggregate's `day`) - Queries without `status = completed` or with a broader `status` filter -- Queries with [Parameters](/semantic-layer/parameters), or with [user attributes](/workspace-admin/user-attributes) referenced from a dimension or metric SQL expression (user attributes in [`sql_filter`](#sql-filter-and-pre-aggregates) are supported) +- Queries with [Parameters](/semantic-layer/parameters), or with [user attributes](/workspace-admin/user-attributes) referenced from a dimension or metric SQL expression (user attributes in [`sql_filter`](#sql_filter-and-pre-aggregates) are supported) - Queries including a non-additive metric like `count_distinct` unless they select exactly the pre-aggregate's dimensions at exactly its granularity (see [Exact match queries](#exact-match-queries)) - Queries with raw SQL table calculations diff --git a/semantic-layer/pre-aggregates/external.mdx b/semantic-layer/pre-aggregates/external.mdx index d1e95ffe..6de14392 100644 --- a/semantic-layer/pre-aggregates/external.mdx +++ b/semantic-layer/pre-aggregates/external.mdx @@ -181,7 +181,7 @@ External pre-aggregates split responsibility explicitly: * Compiling the served query against your table in your warehouse's dialect * Re-truncating the stored time dimension for coarser-grain queries (a day-grain table serves week, month, quarter, year) * Re-aggregating `__sum` and `__count` components into `average` metrics at query time -* Applying [`sql_filter`](/semantic-layer/pre-aggregates#sql-filter-and-pre-aggregates) — rewritten onto the external table's columns, with `${lightdash.*}` substituted for the querying user — plus model [required filters](/semantic-layer/tables#default-filters) and [required attributes](/semantic-layer/tables#required-attributes) at serve time. Field references in `sql_filter` must be pre-aggregate dimensions; non-field references (`${TABLE}.col`, hand-written `table.col`) pass through verbatim and must exist in the external table under those raw names. +* Applying [`sql_filter`](/semantic-layer/pre-aggregates#sql_filter-and-pre-aggregates) — rewritten onto the external table's columns, with `${lightdash.*}` substituted for the querying user — plus model [required filters](/semantic-layer/tables#default-filters) and [required attributes](/semantic-layer/tables#required-attributes) at serve time. Field references in `sql_filter` must be pre-aggregate dimensions; non-field references (`${TABLE}.col`, hand-written `table.col`) pass through verbatim and must exist in the external table under those raw names. * Falling back to the warehouse per query if serving errors (missing table, missing column, type mismatch) * Recording hits and misses in [pre-aggregate analytics](/semantic-layer/pre-aggregates/monitoring#hit-and-miss-statistics) and the [dashboard audit](/semantic-layer/pre-aggregates/monitoring#dashboard-pre-aggregate-view) diff --git a/semantic-layer/pre-aggregates/monitoring.mdx b/semantic-layer/pre-aggregates/monitoring.mdx index 29f3bb22..b8a26439 100644 --- a/semantic-layer/pre-aggregates/monitoring.mdx +++ b/semantic-layer/pre-aggregates/monitoring.mdx @@ -55,7 +55,7 @@ When a query doesn't match any pre-aggregate, Lightdash records the specific rea | **Dimension not in pre-aggregate** | The query includes a dimension not covered by any pre-aggregate. | Add the missing dimension to your pre-aggregate's `dimensions` list. | | **Metric not in pre-aggregate** | The query includes a metric not covered by any pre-aggregate. | Add the missing metric to your pre-aggregate's `metrics` list. | | **Filter dimension not in pre-aggregate** | A filter references a dimension not in the pre-aggregate, or a model [`required_filters`](/semantic-layer/pre-aggregates#required-filters-and-pre-aggregates) target is missing from it. | Add the filter dimension to the `dimensions` list — even if it's only used for filtering, not grouping. | -| **`sql_filter` field not in pre-aggregate** | The model's [`sql_filter`](/semantic-layer/tables#sql-filter-row-level-security) references a field (for example `${customers.segment}`) that isn't a covered dimension of the pre-aggregate, so the filter cannot be rewritten onto the materialization. | Add every field referenced by `sql_filter` to the pre-aggregate's `dimensions` list. See [`sql_filter` and pre-aggregates](/semantic-layer/pre-aggregates#sql-compatibility). | +| **`sql_filter` field not in pre-aggregate** | The model's [`sql_filter`](/semantic-layer/tables#sql-filter-row-level-security) references a field (for example `${customers.segment}`) that isn't a covered dimension of the pre-aggregate, so the filter cannot be rewritten onto the materialization. | Add every field referenced by `sql_filter` to the pre-aggregate's `dimensions` list. See [`sql_filter` and pre-aggregates](/semantic-layer/pre-aggregates#sql_filter-and-pre-aggregates). | | **Pre-aggregate filter not satisfied** | The query's filter doesn't [match the pre-aggregate's](/semantic-layer/pre-aggregates#how-query-matching-works-with-filters), or the pre-aggregate's `filters` block [targets a required-filter field](/semantic-layer/pre-aggregates#required-filters-and-pre-aggregates). | Narrow the query filter and match the pre-aggregate filter's operator, remove any pre-aggregate `filters` on required-filter fields, or create another pre-aggregate for that query pattern. | | **Non-additive metric** | The query includes a metric type that can't be re-aggregated (for example, `count_distinct` or `median`) and it isn't an [exact match](/semantic-layer/pre-aggregates#exact-match-queries) of any pre-aggregate. | Define a pre-aggregate whose dimensions and granularity match how the metric is queried, so the query can serve as an exact match. See [supported metric types](/semantic-layer/pre-aggregates#supported-metric-types). | | **Non-additive metric: select exactly the pre-aggregate dimensions** | The query includes a non-additive metric (`count_distinct`, `median`, `percentile`, etc.) and the pre-aggregate's dimensions cover it, but the query didn't select every pre-aggregate dimension at exactly its granularity — so no [exact match](/semantic-layer/pre-aggregates#exact-match-queries). | Select every one of the pre-aggregate's dimensions and use its exact granularity, or drop the non-additive metric. | diff --git a/semantic-layer/tables.mdx b/semantic-layer/tables.mdx index 875e6083..156ed476 100644 --- a/semantic-layer/tables.mdx +++ b/semantic-layer/tables.mdx @@ -198,7 +198,7 @@ explores: | [groups](#groups) | array of strings | Group tables in the sidebar, with up to 5 levels of nesting. [Read about groups.](#groups) | | group_label | string | Deprecated Use [`groups`](#groups) instead. Group tables in the sidebar. | | [sql_from](#sql-from) | string | Overrides dbt model relation_name | -| [sql_filter](#sql-filter-row-level-security) | string | A permanent filter that will always be applied when querying this table directly. [`Read about sql_filter.`](#sql-filter) | +| [sql_filter](#sql-filter-row-level-security) | string | A permanent filter that will always be applied when querying this table directly. [`Read about sql_filter.`](#sql-filter-row-level-security) | | [sql_where](#sql-filter-row-level-security) | string | Alias for `sql_filter` | | [required_attributes](#required-attributes) | object | Limits access to users with those attributes (AND logic). [Read about user attributes](/workspace-admin/user-attributes) | | [any_attributes](#any-attributes) | object | Limits access to users with those attributes (OR logic). [Read about user attributes](/workspace-admin/user-attributes) | diff --git a/workflow/cli/reference.mdx b/workflow/cli/reference.mdx index 1b085556..823fc317 100644 --- a/workflow/cli/reference.mdx +++ b/workflow/cli/reference.mdx @@ -1225,7 +1225,10 @@ Preview a rename and its local file changes: ```bash lightdash slug-update --dry-run --from copy-of-orders --to orders +``` + Rename a chart and update a custom content-as-code directory: + ```bash lightdash slug-update \ --from copy-of-orders \ diff --git a/workflow/rename-models-and-fields.mdx b/workflow/rename-models-and-fields.mdx index edc2e4ec..14f46a89 100644 --- a/workflow/rename-models-and-fields.mdx +++ b/workflow/rename-models-and-fields.mdx @@ -85,4 +85,4 @@ The CLI will show you which charts, dashboards, alerts, and dashboard schedulers ## Reverting changes -When renaming, a new chart version is created with the new changes. If you make a mistake during renaming, you can restore individual charts by using [version history](/explore/version-history#chart-version-history). \ No newline at end of file +When renaming, a new chart version is created with the new changes. If you make a mistake during renaming, you can restore individual charts by using [version history](/explore/version-history#charts). \ No newline at end of file diff --git a/workspace-admin/service-accounts.mdx b/workspace-admin/service-accounts.mdx index 1b60a047..c24e19dd 100644 --- a/workspace-admin/service-accounts.mdx +++ b/workspace-admin/service-accounts.mdx @@ -170,11 +170,11 @@ For full API documentation, see the [API Reference](/api-reference/v1/introducti ### CI/CD automation -Use service accounts to automatically deploy dbt changes to Lightdash in your CI/CD pipeline. See [deploying with GitHub Actions](/integrations/dbt/projects#1-automatically%3A-deploy-your-changes-to-lightdash-using-a-github-action) for implementation details. +Use service accounts to automatically deploy dbt changes to Lightdash in your CI/CD pipeline. See [deploying with GitHub Actions](/workflow/set-up-ci-cd#deploy-changes-to-lightdash) for implementation details. ### Instance initialization -When setting up a new self-hosted instance, configure `LD_SETUP_SERVICE_ACCOUNT_TOKEN` to initialize with a service account. See the [environment variables guide](/self-host/customize-deployment/environment-variables#initialize-instance) for details. +When setting up a new self-hosted instance, configure `LD_SETUP_SERVICE_ACCOUNT_TOKEN` to initialize with a service account. See the [environment variables guide](/self-host/customize-deployment/environment-variables#initialize-instance-enterprise) for details. ### Automated reporting