From 6b9914a70fdf8231c8e0a5ca5a596d04ab91c7df Mon Sep 17 00:00:00 2001 From: Francisco Valdez de la Fuente Date: Mon, 10 Feb 2025 12:34:58 -0800 Subject: [PATCH] Mention the usage of CUBE object. --- docs/pages/product/data-modeling/syntax.mdx | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/docs/pages/product/data-modeling/syntax.mdx b/docs/pages/product/data-modeling/syntax.mdx index 2939745e1b67e..cbe2b77031af7 100644 --- a/docs/pages/product/data-modeling/syntax.mdx +++ b/docs/pages/product/data-modeling/syntax.mdx @@ -95,6 +95,10 @@ Good examples of names: When defining cubes, you would often provide SQL snippets in `sql` and `sql_table` parameters. +You should include a reference to the object that the column belongs to. +In most cases, this reference should be the same cube in which +you are defining the element (`CUBE`). + Provided SQL expressions should match your database SQL dialect, e.g., to aggregate a list of strings, you would probably pick the [`LISTAGG` function][link-snowflake-listagg] in Snowflake and the [`STRING_AGG` @@ -109,12 +113,12 @@ cubes: measures: - name: statuses - sql: "STRING_AGG(status)" + sql: "STRING_AGG({CUBE}.status)" type: string dimensions: - name: status - sql: "UPPER(status)" + sql: "UPPER({CUBE}.status)" type: string ``` @@ -124,14 +128,14 @@ cube(`orders`, { measures: { statuses: { - sql: `STRING_AGG(status)`, + sql: `STRING_AGG(${CUBE}.status)`, type: `string`, }, }, dimensions: { status: { - sql: `UPPER(status)`, + sql: `UPPER(${CUBE}.status)`, type: `string`, }, }, @@ -693,4 +697,4 @@ defining dynamic data models. [ref-custom-granularities]: /reference/data-model/dimensions#granularities [ref-style-guide]: /guides/style-guide [ref-polymorphism]: /product/data-modeling/concepts/polymorphic-cubes -[ref-data-blending]: /product/data-modeling/concepts/data-blending \ No newline at end of file +[ref-data-blending]: /product/data-modeling/concepts/data-blending