From e619ffa000b727d7315d4db1730475c778194391 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Wed, 6 Dec 2023 16:51:07 -0800 Subject: [PATCH 01/28] Update sl-jdbc.md We're making some changes to our API (not released yet), so I'm preemptively adding info. --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index aba309566f8..b250c9a7818 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -254,11 +254,14 @@ Where filters in API allow for a filter list or string. We recommend using the f Where Filters have a few objects that you can use: -- `Dimension()` - Used for any categorical or time dimensions. If used for a time dimension, granularity is required - `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` +- `Dimension()` - Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` - `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` -Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimesion` input takes the time dimension name and also requires granularity, like this: `TimeDimension('metric_time', 'MONTH')`. + +Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimesion` input takes the time dimension name and also requires granularity, like this: `TimeDimension('metric_time', 'month')`. + +For both `TimeDimension()` and `Dimension()` objects, the grain is only required if the aggregation time dimension for the measures / metrics associated with the where filter is not the same for all measures. - Use the following example to query using a `where` filter with the string format: @@ -315,7 +318,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], order_by=[-'order_gross_profit'] }} ``` -If you are ordering by an object that's been operated on (e.g., change granularity), or you are using the full object notation, descending order must look like: +If you are ordering by an object that's been operated on (e.g., you changed the the granularity of the time dimension), or you are using the full object notation, descending order must look like: ```bash select * from {{ From dc49f197ec31317f2b069c64c413eb9f4804274a Mon Sep 17 00:00:00 2001 From: rpourzand Date: Thu, 7 Dec 2023 17:55:44 -0800 Subject: [PATCH 02/28] Update sl-jdbc.md Adding an example from Paul --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 60 ++++++++++++++++++++- 1 file changed, 58 insertions(+), 2 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index b250c9a7818..2a9c5e95199 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -259,9 +259,65 @@ Where Filters have a few objects that you can use: - `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` -Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimesion` input takes the time dimension name and also requires granularity, like this: `TimeDimension('metric_time', 'month')`. +Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimension` input takes the time dimension name and also requires granularity, like this: `TimeDimension('metric_time', 'month')`. + +For both `TimeDimension()` and `Dimension()` objects, the grain is only required if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. + +For example, consider this Semantic Model and Metric Config which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. + +```yaml +--- +semantic_model: + name: my_model_source + +defaults: + agg_time_dimension: created_month + + measures: + - name: measure_0 + agg: sum + - name: measure_1 + agg: sum + agg_time_dimension: order_year + + dimensions: + - name: created_month + type: time + type_params: + time_granularity: month + - name: order_year + type: time + time_granularity: year +... + + +metrics: + name: metric_0 + description: A metric with a month grain. + type: simple + type_params: + measure: measure_0 + + name: metric_1 + description: A metric with a year grain + type: simple + type_params: + measure: measure_1 + +``` + +Assuming the user is querying metric_0 and metric_1 together, a valid filter would be: + + * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` + +Invalid Filters would be: + + `* "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query + are defined based on measures with different grains. + + * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - + metric_1 is not available at a month grain. -For both `TimeDimension()` and `Dimension()` objects, the grain is only required if the aggregation time dimension for the measures / metrics associated with the where filter is not the same for all measures. - Use the following example to query using a `where` filter with the string format: From be5c52c0a68fd2f5e2a9958661e52eefb7640511 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Thu, 7 Dec 2023 17:57:48 -0800 Subject: [PATCH 03/28] Update sl-graphql.md copying the same over for jdbc -- maybe we can figure out a way to put this somewhere so we don't have to duplicate --- .../docs/docs/dbt-cloud-apis/sl-graphql.md | 63 ++++++++++++++++++- 1 file changed, 60 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index b7d13d0d453..0fd55397bc9 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -432,18 +432,18 @@ mutation { The `where` filter takes a list argument (or a string for a single input). Depending on the object you are filtering, there are a couple of parameters: - - `Dimension()` — Used for any categorical or time dimensions. If used for a time dimension, granularity is required. For example, `Dimension('metric_time').grain('week')` or `Dimension('customer__country')`. + - `Dimension()` — Used for any categorical or time dimensions. For example, `Dimension('metric_time').grain('week')` or `Dimension('customer__country')`. - `Entity()` — Used for entities like primary and foreign keys, such as `Entity('order_id')`. -Note: If you prefer a more strongly typed `where` clause, you can optionally use `TimeDimension()` to separate out categorical dimensions from time ones. The `TimeDimension` input takes the time dimension name and also requires granularity. For example, `TimeDimension('metric_time', 'MONTH')`. +Note: If you prefer a more strongly typed `where` clause, you can optionally use `TimeDimension()` to separate out categorical dimensions from time ones. The `TimeDimension` input takes the time dimension and optionally the granularity level. `TimeDimension('metric_time', 'month')`. ```graphql mutation { createQuery( environmentId: BigInt! metrics:[{name: "order_total"}] - groupBy:[{name: "customer__customer_type"}, {name: "metric_time", grain: MONTH}] + groupBy:[{name: "customer__customer_type"}, {name: "metric_time", grain: month}] where:[{sql: "{{ Dimension('customer__customer_type') }} = 'new'"}, {sql:"{{ Dimension('metric_time').grain('month') }} > '2022-10-01'"}] ) { queryId @@ -451,6 +451,63 @@ mutation { } ``` +For both `TimeDimension()` and `Dimension()` objects, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. + +For example, consider this Semantic Model and Metric Configuration which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. + +```yaml +--- +semantic_model: + name: my_model_source + +defaults: + agg_time_dimension: created_month + + measures: + - name: measure_0 + agg: sum + - name: measure_1 + agg: sum + agg_time_dimension: order_year + + dimensions: + - name: created_month + type: time + type_params: + time_granularity: month + - name: order_year + type: time + time_granularity: year +... + + +metrics: + name: metric_0 + description: A metric with a month grain. + type: simple + type_params: + measure: measure_0 + + name: metric_1 + description: A metric with a year grain + type: simple + type_params: + measure: measure_1 + +``` + +Assuming the user is querying metric_0 and metric_1 together, a valid filter would be: + + * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` + +Invalid Filters would be: + + `* "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query + are defined based on measures with different grains. + + * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - + metric_1 is not available at a month grain. + **Query with Order** ```graphql From 8c510b7c3cf7ca717c2d7a1fcc1337f10ad78726 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Thu, 7 Dec 2023 17:58:45 -0800 Subject: [PATCH 04/28] Update sl-jdbc.md timedimension is no longer optional --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 2a9c5e95199..3c771cc182c 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -259,7 +259,7 @@ Where Filters have a few objects that you can use: - `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` -Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimension` input takes the time dimension name and also requires granularity, like this: `TimeDimension('metric_time', 'month')`. +Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimension` input takes the time dimension name optionally requires granularity, like this: `TimeDimension('metric_time', 'month')`. For both `TimeDimension()` and `Dimension()` objects, the grain is only required if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. From 436577f237fedc60038fb38e7d05ede0d97695d8 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Thu, 7 Dec 2023 18:00:09 -0800 Subject: [PATCH 05/28] Update sl-jdbc.md fixing some updates --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 3c771cc182c..220d4fb2cd4 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -261,7 +261,7 @@ Where Filters have a few objects that you can use: Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimension` input takes the time dimension name optionally requires granularity, like this: `TimeDimension('metric_time', 'month')`. -For both `TimeDimension()` and `Dimension()` objects, the grain is only required if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. +For both `TimeDimension()` and `Dimension()` objects, the grain is only required if in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. For example, consider this Semantic Model and Metric Config which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. @@ -287,10 +287,10 @@ defaults: time_granularity: month - name: order_year type: time - time_granularity: year + type_params: + time_granularity: year ... - metrics: name: metric_0 description: A metric with a month grain. @@ -306,7 +306,7 @@ metrics: ``` -Assuming the user is querying metric_0 and metric_1 together, a valid filter would be: +Assuming the user is querying metric_0 and metric_1 together in a single request, a valid WHERE filter would be: * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` From c250bb6490a1d4646d53907378cc789b9a283567 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Thu, 7 Dec 2023 18:00:59 -0800 Subject: [PATCH 06/28] Update sl-graphql.md fixing typo --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 0fd55397bc9..163380bb647 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -477,7 +477,8 @@ defaults: time_granularity: month - name: order_year type: time - time_granularity: year + type_params: + time_granularity: year ... From 61af03e70e666c1e702dca66428bed253b092f5a Mon Sep 17 00:00:00 2001 From: rpourzand Date: Fri, 8 Dec 2023 14:52:59 -0800 Subject: [PATCH 07/28] Update sl-graphql.md making paul's reco's --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 163380bb647..7b4eeddfee6 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -436,7 +436,7 @@ The `where` filter takes a list argument (or a string for a single input). Depen - `Entity()` — Used for entities like primary and foreign keys, such as `Entity('order_id')`. -Note: If you prefer a more strongly typed `where` clause, you can optionally use `TimeDimension()` to separate out categorical dimensions from time ones. The `TimeDimension` input takes the time dimension and optionally the granularity level. `TimeDimension('metric_time', 'month')`. +Note: If you prefer a `where` clause with a more explicit path, you can optionally use `TimeDimension()` to separate out categorical dimensions from time ones. The `TimeDimension` input takes the time dimension and optionally the granularity level. `TimeDimension('metric_time', 'month')`. ```graphql mutation { @@ -502,8 +502,8 @@ Assuming the user is querying metric_0 and metric_1 together, a valid filter wou * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` Invalid Filters would be: - - `* "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query + + * ` "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query are defined based on measures with different grains. * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - From c5afac9f933dc2bba6aa7f28c5f782afd2ba1448 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Fri, 8 Dec 2023 14:53:53 -0800 Subject: [PATCH 08/28] Update sl-jdbc.md paul's recos --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 220d4fb2cd4..b1d90721d24 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -312,7 +312,7 @@ Assuming the user is querying metric_0 and metric_1 together in a single request Invalid Filters would be: - `* "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query + * `"{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query are defined based on measures with different grains. * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - From 384eba8856f59a341af767b744dc866673f9d66a Mon Sep 17 00:00:00 2001 From: rpourzand Date: Tue, 19 Dec 2023 10:59:29 -0800 Subject: [PATCH 09/28] Update sl-graphql.md also adding a dimension only example to it --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 3591c36cbd3..774b0c53d87 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -204,6 +204,8 @@ DimensionType = [CATEGORICAL, TIME] ### Querying +When querying for data, _either_ a `groupBy` _or_ a `metrics` selection is required. + **Create Dimension Values query** ```graphql @@ -428,6 +430,19 @@ mutation { } ``` +**Query a categorical dimension on its own** + +```graphql +mutation { + createQuery( + environmentId: 123456 + groupBy: [{name: "customer__customer_type"}] + ) { + queryId + } +} +``` + **Query with a where filter** The `where` filter takes a list argument (or a string for a single input). Depending on the object you are filtering, there are a couple of parameters: From bc2239ac113dcbeff4e97830768475ada91b4c9b Mon Sep 17 00:00:00 2001 From: rpourzand Date: Wed, 20 Dec 2023 17:07:12 -0800 Subject: [PATCH 10/28] Update sl-jdbc.md updating per jordan's input --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 69428878f80..a1f79208e6d 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -256,12 +256,12 @@ Where Filters have a few objects that you can use: - `Dimension()` - Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` -- `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` +- `TimeDimension()` - Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` +- `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` -Note: If you prefer a more explicit path to create the `where` clause, you can optionally use the `TimeDimension` feature. This helps separate out categorical dimensions from time-related ones. The `TimeDimension` input takes the time dimension name optionally requires granularity, like this: `TimeDimension('metric_time', 'month')`. -For both `TimeDimension()` and `Dimension()` objects, the grain is only required if in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. +For `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. For example, consider this Semantic Model and Metric Config which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. From a73e79398bb432a46133c729594eafe8ba3a4743 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:23:45 -0500 Subject: [PATCH 11/28] Update sl-graphql.md format yaml --- .../docs/docs/dbt-cloud-apis/sl-graphql.md | 41 ++++++++----------- 1 file changed, 16 insertions(+), 25 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 774b0c53d87..28ac38936ca 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -471,20 +471,17 @@ For both `TimeDimension()` and `Dimension()` objects, the grain is only required For example, consider this Semantic Model and Metric Configuration which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. ```yaml ---- semantic_model: name: my_model_source - -defaults: - agg_time_dimension: created_month +defaults: + agg_time_dimension: created_month measures: - name: measure_0 agg: sum - name: measure_1 agg: sum agg_time_dimension: order_year - dimensions: - name: created_month type: time @@ -494,35 +491,29 @@ defaults: type: time type_params: time_granularity: year -... - metrics: - name: metric_0 - description: A metric with a month grain. - type: simple - type_params: - measure: measure_0 - - name: metric_1 - description: A metric with a year grain - type: simple - type_params: - measure: measure_1 - + - name: metric_0 + description: A metric with a month grain. + type: simple + type_params: + measure: measure_0 + - name: metric_1 + description: A metric with a year grain. + type: simple + type_params: + measure: measure_1 ``` -Assuming the user is querying metric_0 and metric_1 together, a valid filter would be: +Assuming the user is querying `metric_0` and `metric_1` together, a valid filter would be: * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` -Invalid Filters would be: +Invalid filters would be: - * ` "{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query - are defined based on measures with different grains. + * ` "{{ TimeDimension('metric_time') }} > '2020-01-01'"` — metrics in the query b are defined based on measures with different grains. - * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - - metric_1 is not available at a month grain. + * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` — `metric_1` is not available at a month grain. **Query with Order** From ceea7dc2bc35825d1dfd8ed26c2dbf9e616e7bef Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:25:26 -0500 Subject: [PATCH 12/28] Update website/docs/docs/dbt-cloud-apis/sl-graphql.md --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 28ac38936ca..77d50d1d293 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -468,7 +468,7 @@ mutation { For both `TimeDimension()` and `Dimension()` objects, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. -For example, consider this Semantic Model and Metric Configuration which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. +For example, consider this Semantic model and Metric configuration, which contains two metrics that are aggregated across different time grains. This example shows a single semantic model, but the same goes for metrics across more than one semantic model. ```yaml semantic_model: From 5f832e9d6ecb9468aeb615ef66f227203e7360f5 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:25:50 -0500 Subject: [PATCH 13/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index a1f79208e6d..09fb73c1c9f 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -254,7 +254,7 @@ Where filters in API allow for a filter list or string. We recommend using the f Where Filters have a few objects that you can use: -- `Dimension()` - Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` +- `Dimension()` — Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` - `TimeDimension()` - Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` From 1b774190a0e67f9c7e5641eddb687f16bd025e70 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:26:04 -0500 Subject: [PATCH 14/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 09fb73c1c9f..32e57208126 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -256,7 +256,7 @@ Where Filters have a few objects that you can use: - `Dimension()` — Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` -- `TimeDimension()` - Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` +- `TimeDimension()` — Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` - `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` From e06152133bcd3184181cfc371ba05152b45ae626 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:26:29 -0500 Subject: [PATCH 15/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 32e57208126..98fe99fc713 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -258,7 +258,7 @@ Where Filters have a few objects that you can use: - `TimeDimension()` — Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` -- `Entity()` - Used for entities like primary and foreign keys - `Entity('order_id')` +- `Entity()` — Used for entities like primary and foreign keys - `Entity('order_id')` For `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. From 7aa722d1e834b64b74451d79637adeafae1a137d Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:28:37 -0500 Subject: [PATCH 16/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 98fe99fc713..60fd45d2424 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -261,7 +261,7 @@ Where Filters have a few objects that you can use: - `Entity()` — Used for entities like primary and foreign keys - `Entity('order_id')` -For `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. +For `TimeDimension()`, the grain is only required in the `WHERE` filter if the aggregation time dimensions for the measures and metrics associated with the where filter have different grains. For example, consider this Semantic Model and Metric Config which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. From 7dc125e79f33ec8dba66c98534a581eca4791b20 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:34:29 -0500 Subject: [PATCH 17/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 60fd45d2424..b6eb03affde 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -263,7 +263,7 @@ Where Filters have a few objects that you can use: For `TimeDimension()`, the grain is only required in the `WHERE` filter if the aggregation time dimensions for the measures and metrics associated with the where filter have different grains. -For example, consider this Semantic Model and Metric Config which contains two metrics that are aggregated across different time grains. This example shows a single Semantic Model, but the same goes for metrics across more than one Semantic Model. +For example, consider this Semantic model and Metric config, which contains two metrics that are aggregated across different time grains. This example shows a single semantic model, but the same goes for metrics across more than one semantic model. ```yaml --- From ece5d3f662660a66ab6d971272d2cc22c12ca966 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Thu, 21 Dec 2023 09:39:20 -0500 Subject: [PATCH 18/28] Update sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 70 +++++++++++---------- 1 file changed, 36 insertions(+), 34 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index b6eb03affde..41d57994cc7 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -177,8 +177,6 @@ To query metric values, here are the following parameters that are available: |`order` | Order the data returned by a particular field | `order_by=['order_gross_profit']`, use `-` for descending, or full object notation if the object is operated on: `order_by=[Metric('order_gross_profit').descending(True)`] | Optional | | `compile` | If true, returns generated SQL for the data platform but does not execute | `compile=True` | Optional | - - ## Note on time dimensions and `metric_time` You will notice that in the list of dimensions for all metrics, there is a dimension called `metric_time`. `Metric_time` is a reserved keyword for the measure-specific aggregation time dimensions. For any time-series metric, the `metric_time` keyword should always be available for use in queries. This is a common dimension across *all* metrics in a semantic graph. @@ -266,20 +264,17 @@ For `TimeDimension()`, the grain is only required in the `WHERE` filter if the a For example, consider this Semantic model and Metric config, which contains two metrics that are aggregated across different time grains. This example shows a single semantic model, but the same goes for metrics across more than one semantic model. ```yaml ---- semantic_model: name: my_model_source - -defaults: - agg_time_dimension: created_month +defaults: + agg_time_dimension: created_month measures: - name: measure_0 agg: sum - name: measure_1 agg: sum agg_time_dimension: order_year - dimensions: - name: created_month type: time @@ -288,36 +283,31 @@ defaults: - name: order_year type: time type_params: - time_granularity: year -... + time_granularity: year metrics: - name: metric_0 - description: A metric with a month grain. - type: simple - type_params: - measure: measure_0 - - name: metric_1 - description: A metric with a year grain - type: simple - type_params: - measure: measure_1 + - name: metric_0 + description: A metric with a month grain. + type: simple + type_params: + measure: measure_0 + - name: metric_1 + description: A metric with a year grain. + type: simple + type_params: + measure: measure_1 ``` -Assuming the user is querying metric_0 and metric_1 together in a single request, a valid WHERE filter would be: +Assuming the user is querying `metric_0` and `metric_1` together in a single request, a valid `WHERE` filter would be: * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` Invalid Filters would be: - * `"{{ TimeDimension('metric_time') }} > '2020-01-01'"` - metrics in the query - are defined based on measures with different grains. - - * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` - - metric_1 is not available at a month grain. + * `"{{ TimeDimension('metric_time') }} > '2020-01-01'"` — metrics in the query are defined based on measures with different grains. + * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` — `metric_1` is not available at a month grain. - Use the following example to query using a `where` filter with the string format: @@ -350,7 +340,8 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], group_by=[Dimension('metric_time')], limit=10) }} -``` +``` + ### Query with Order By Examples Order By can take a basic string that's a Dimension, Metric, or Entity and this will default to ascending order @@ -373,7 +364,8 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], limit=10, order_by=[-'order_gross_profit'] }} -``` +``` + If you are ordering by an object that's been operated on (e.g., you changed the the granularity of the time dimension), or you are using the full object notation, descending order must look like: ```bash @@ -413,14 +405,24 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], -- **Why do some dimensions use different syntax, like `metric_time` versus `[Dimension('metric_time')`?**
- When you select a dimension on its own, such as `metric_time` you can use the shorthand method which doesn't need the “Dimension” syntax. However, when you perform operations on the dimension, such as adding granularity, the object syntax `[Dimension('metric_time')` is required. + + +When you select a dimension on its own, such as `metric_time` you can use the shorthand method which doesn't need the “Dimension” syntax. However, when you perform operations on the dimension, such as adding granularity, the object syntax `[Dimension('metric_time')` is required. + + + + + +The double underscore `"__"` syntax indicates a mapping from an entity to a dimension, as well as where the dimension is located. For example, `user__country` means someone is looking at the `country` dimension from the `user` table. + + + -- **What does the double underscore `"__"` syntax in dimensions mean?**
- The double underscore `"__"` syntax indicates a mapping from an entity to a dimension, as well as where the dimension is located. For example, `user__country` means someone is looking at the `country` dimension from the `user` table. + + +The default output follows the format `{time_dimension_name}__{granularity_level}`. So for example, if the time dimension name is `ds` and the granularity level is yearly, the output is `ds__year`. -- **What is the default output when adding granularity?**
- The default output follows the format `{time_dimension_name}__{granularity_level}`. So for example, if the time dimension name is `ds` and the granularity level is yearly, the output is `ds__year`. + ## Related docs From b7cd78a646175341f0632b7a89027f4d89e34491 Mon Sep 17 00:00:00 2001 From: mirnawong1 Date: Thu, 21 Dec 2023 10:05:47 -0500 Subject: [PATCH 19/28] add toggles --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 41d57994cc7..b3d9b961957 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -403,24 +403,24 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], ## FAQs - +
- - -When you select a dimension on its own, such as `metric_time` you can use the shorthand method which doesn't need the “Dimension” syntax. However, when you perform operations on the dimension, such as adding granularity, the object syntax `[Dimension('metric_time')` is required. + +When you select a dimension on its own, such as `metric_time` you can use the shorthand method which doesn't need the “Dimension” syntax. +However, when you perform operations on the dimension, such as adding granularity, the object syntax `[Dimension('metric_time')` is required. - + The double underscore `"__"` syntax indicates a mapping from an entity to a dimension, as well as where the dimension is located. For example, `user__country` means someone is looking at the `country` dimension from the `user` table. - - - -The default output follows the format `{time_dimension_name}__{granularity_level}`. So for example, if the time dimension name is `ds` and the granularity level is yearly, the output is `ds__year`. + +The default output follows the format `{{time_dimension_name}__{granularity_level}}`. + +So for example, if the `time_dimension_name` is `ds` and the granularity level is yearly, the output is `ds__year`. From 7b8cc9ad8da5b62d89a03e1bddb40173fd473d27 Mon Sep 17 00:00:00 2001 From: Matt Shaver <60105315+matthewshaver@users.noreply.github.com> Date: Fri, 22 Dec 2023 14:24:36 -0500 Subject: [PATCH 20/28] Apply suggestions from code review --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index b3d9b961957..6c57cdec161 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -252,11 +252,11 @@ Where filters in API allow for a filter list or string. We recommend using the f Where Filters have a few objects that you can use: -- `Dimension()` — Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')` +- `Dimension()` — Used for any categorical or time dimensions. `Dimension('metric_time').grain('week')` or `Dimension('customer__country')`. -- `TimeDimension()` — Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')` +- `TimeDimension()` — Used as a more explicit definition for time dimensions, optionally takes in a granularity `TimeDimension('metric_time', 'month')`. -- `Entity()` — Used for entities like primary and foreign keys - `Entity('order_id')` +- `Entity()` — Used for entities like primary and foreign keys - `Entity('order_id')`. For `TimeDimension()`, the grain is only required in the `WHERE` filter if the aggregation time dimensions for the measures and metrics associated with the where filter have different grains. From 6a32ba682ad541a89b71060a130ef1ea1d5f3979 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Fri, 19 Jan 2024 17:17:23 -0800 Subject: [PATCH 21/28] Update sl-graphql.md --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index fc095985160..9bef3c039f3 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -513,7 +513,7 @@ Assuming the user is querying `metric_0` and `metric_1` together, a valid filter Invalid filters would be: - * ` "{{ TimeDimension('metric_time') }} > '2020-01-01'"` — metrics in the query b are defined based on measures with different grains. + * ` "{{ TimeDimension('metric_time') }} > '2020-01-01'"` — metrics in the query are defined based on measures with different grains. * `"{{ TimeDimension('metric_time', 'month') }} > '2020-01-01'"` — `metric_1` is not available at a month grain. From 1d053634a3325ef1d6b1102e431de7f3bc01b240 Mon Sep 17 00:00:00 2001 From: rpourzand Date: Fri, 19 Jan 2024 17:18:33 -0800 Subject: [PATCH 22/28] Update sl-graphql.md --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 9bef3c039f3..230f84b0b98 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -468,7 +468,7 @@ mutation { } ``` -For both `TimeDimension()` and `Dimension()` objects, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. +For both `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. For example, consider this Semantic model and Metric configuration, which contains two metrics that are aggregated across different time grains. This example shows a single semantic model, but the same goes for metrics across more than one semantic model. From 357e5aa2e3489305f2f759638d9c18716ac5d50b Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:26:05 +0000 Subject: [PATCH 23/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 7296d1541ab..7b2b1438ae9 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -378,7 +378,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], }} ``` -If you are ordering by an object that's been operated on (e.g., you changed the the granularity of the time dimension), or you are using the full object notation, descending order must look like: +If you are ordering by an object that's been operated on (for example, you changed the the granularity of the time dimension), or you are using the full object notation, descending order must look like: ```bash select * from {{ From 192c2f01be98826adebacd7dd2627763796fc75a Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:27:47 +0000 Subject: [PATCH 24/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 7b2b1438ae9..6ff846fa7c7 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -315,7 +315,7 @@ Assuming the user is querying `metric_0` and `metric_1` together in a single req * `"{{ TimeDimension('metric_time', 'year') }} > '2020-01-01'"` -Invalid Filters would be: +Invalid filters would be: * `"{{ TimeDimension('metric_time') }} > '2020-01-01'"` — metrics in the query are defined based on measures with different grains. From 250b3ba78d8cb759089a0fa3bc045ae88dd8e587 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:28:47 +0000 Subject: [PATCH 25/28] Update website/docs/docs/dbt-cloud-apis/sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 6ff846fa7c7..6916f283898 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -415,7 +415,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], ## FAQs -
+ When you select a dimension on its own, such as `metric_time` you can use the shorthand method which doesn't need the “Dimension” syntax. From fb3b8f69b3f762e16736aed47bf1d5fb8111bf33 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:30:05 +0000 Subject: [PATCH 26/28] Update website/docs/docs/dbt-cloud-apis/sl-graphql.md --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 7a857f45087..177883ce19b 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -481,7 +481,7 @@ mutation { } ``` -For both `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures & metrics associated with the where filter have different grains. +For both `TimeDimension()`, the grain is only required in the WHERE filter if the aggregation time dimensions for the measures and metrics associated with the where filter have different grains. For example, consider this Semantic model and Metric configuration, which contains two metrics that are aggregated across different time grains. This example shows a single semantic model, but the same goes for metrics across more than one semantic model. From 610da3815e16fef976b47ff3d4b39b4b2980b154 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:31:04 +0000 Subject: [PATCH 27/28] Update sl-graphql.md --- website/docs/docs/dbt-cloud-apis/sl-graphql.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-graphql.md b/website/docs/docs/dbt-cloud-apis/sl-graphql.md index 177883ce19b..f26a19a1930 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-graphql.md +++ b/website/docs/docs/dbt-cloud-apis/sl-graphql.md @@ -466,7 +466,7 @@ The `where` filter takes a list argument (or a string for a single input). Depen - `Entity()` — Used for entities like primary and foreign keys, such as `Entity('order_id')`. -Note: If you prefer a `where` clause with a more explicit path, you can optionally use `TimeDimension()` to separate out categorical dimensions from time ones. The `TimeDimension` input takes the time dimension and optionally the granularity level. `TimeDimension('metric_time', 'month')`. +Note: If you prefer a `where` clause with a more explicit path, you can optionally use `TimeDimension()` to separate categorical dimensions from time ones. The `TimeDimension` input takes the time dimension and optionally the granularity level. `TimeDimension('metric_time', 'month')`. ```graphql mutation { From 7f3cc44c400ac2b56c265e4fb7a4d4292d6efa08 Mon Sep 17 00:00:00 2001 From: mirnawong1 <89008547+mirnawong1@users.noreply.github.com> Date: Tue, 23 Jan 2024 11:33:20 +0000 Subject: [PATCH 28/28] Update sl-jdbc.md --- website/docs/docs/dbt-cloud-apis/sl-jdbc.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md index 6916f283898..5ef0c071c10 100644 --- a/website/docs/docs/dbt-cloud-apis/sl-jdbc.md +++ b/website/docs/docs/dbt-cloud-apis/sl-jdbc.md @@ -92,9 +92,9 @@ select * from {{ -Use this query to fetch dimension values for one or multiple metrics and single dimension. +Use this query to fetch dimension values for one or multiple metrics and a single dimension. -Note, `metrics` is a required argument that lists one or multiple metrics in it, and a single dimension. +Note, `metrics` is a required argument that lists one or multiple metrics, and a single dimension. ```bash select * from {{ @@ -105,9 +105,9 @@ semantic_layer.dimension_values(metrics=['food_order_amount'], group_by=['custom -Use this query to fetch queryable granularities for a list of metrics. This API request allows you to only show the time granularities that make sense for the primary time dimension of the metrics (such as `metric_time`), but if you want queryable granularities for other time dimensions, you can use the `dimensions()` call, and find the column queryable_granularities. +You can use this query to fetch queryable granularities for a list of metrics. This API request allows you to only show the time granularities that make sense for the primary time dimension of the metrics (such as `metric_time`), but if you want queryable granularities for other time dimensions, you can use the `dimensions()` call, and find the column queryable_granularities. -Note, `metrics` is a required argument that lists one or multiple metrics in it. +Note, `metrics` is a required argument that lists one or multiple metrics. ```bash select * from {{ @@ -124,7 +124,7 @@ select * from {{ Use this query to fetch available metrics given dimensions. This command is essentially the opposite of getting dimensions given a list of metrics. -Note, `group_by` is a required argument that lists one or multiple dimensions in it. +Note, `group_by` is a required argument that lists one or multiple dimensions. ```bash select * from {{ @@ -137,7 +137,7 @@ select * from {{ -Use this example query to fetch available granularities for all time dimesensions (the similar queryable granularities API call only returns granularities for the primary time dimensions for metrics). The following call is a derivative of the `dimensions()` call and specifically selects the granularities field. +You can use this example query to fetch available granularities for all time dimensions (the similar queryable granularities API call only returns granularities for the primary time dimensions for metrics). The following call is a derivative of the `dimensions()` call and specifically selects the granularity field. ```bash select NAME, QUERYABLE_GRANULARITIES from {{ @@ -344,7 +344,7 @@ where=["{{ Dimension('metric_time').grain('month') }} >= '2017-03-09'", "{{ Dime ### Query with a limit -Use the following example to query using a `limit` or `order_by` clauses: +Use the following example to query using a `limit` or `order_by` clause: ```bash select * from {{ @@ -356,7 +356,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], ### Query with Order By Examples -Order By can take a basic string that's a Dimension, Metric, or Entity and this will default to ascending order +Order By can take a basic string that's a Dimension, Metric, or Entity, and this will default to ascending order ```bash select * from {{ @@ -367,7 +367,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], }} ``` -For descending order, you can add a `-` sign in front of the object. However, you can only use this short hand notation if you aren't operating on the object or using the full object notation. +For descending order, you can add a `-` sign in front of the object. However, you can only use this short-hand notation if you aren't operating on the object or using the full object notation. ```bash select * from {{ @@ -378,7 +378,7 @@ semantic_layer.query(metrics=['food_order_amount', 'order_gross_profit'], }} ``` -If you are ordering by an object that's been operated on (for example, you changed the the granularity of the time dimension), or you are using the full object notation, descending order must look like: +If you are ordering by an object that's been operated on (for example, you changed the granularity of the time dimension), or you are using the full object notation, descending order must look like: ```bash select * from {{