@gooddata/sdk-maql-language-server 0.0.0-stage → 11.65.0-alpha.3

package/esm/docs/en/docs/create-metrics/maql/conditionals/ifnull.js

@@ -0,0 +1,96 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# IFNULL
+IFNULL statement allows you to control replacement of missing values that are returned by an expression.
+
+If a metric expression that is wrapped within an IFNULL statement ever returns a null value, the replacement number specified in the second parameter of the IFNULL function is inserted in place of the null value.
+
+IFNULL is useful especially in cases where a sub-metric is referred to within another metric's definition. Wrapping the sub metric in an IFNULL statement keeps the encompassing metric from becoming null due to one of its components returning a null value. 
+
+## Syntax
+
+\`\`\`
+SELECT IFNULL(…,…)
+SELECT IFNULL(metric, replacement_value)
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT IFNULL(SUM({fact/amount}), 0)
+SELECT IFNULL(SUM({metric/fb_cost} + {metric/tw_cost}), 0)
+SELECT IFNULL(SUM({fact/amount}) + 100, 1)
+\`\`\`
+
+Supported replacement values include constants, but not other metric expressions.
+
+## IFNULL Best Practices
+
+The IFNULL function is used to replace missing values in fact tables and to replace values when a computation generates a null value.
+
+A null value is not the same thing as zero (0). A null value means one of the following:
+
+-   no entry has been made
+-   the value is unknown
+
+The IFNULL function can be useful for handling or trapping values that are null, which can confuse your analysis.
+
+However, the function should not be overused, as it can add significant computing time and consume workspace computational bandwidth.
+
+Do not apply IFNULL to all of your functions or even your basic sum, average, and count functions. Instead, use IFNULL where the presence of null values is causing confusion or ambiguity in the visualizations you have created.
+
+Wrapping a metric in the IFNULL statement enables operations where one of the values is null. The syntax for this statement looks like the following:
+
+\`\`\`
+SELECT IFNULL(metric_reference, replacement_value)
+\`\`\`
+
+The IFNULL function can be applied to facts, too.
+
+\`\`\`
+SELECT IFNULL(fact_name, replacement_value)
+\`\`\`
+
+**Example - Data with a missing line item**
+
+An IFNULL does not mean that there is a blank or missing line item.
+
+Suppose your data looks like the following:
+
+  |Date      |   Sales Amounts|
+  |------------| ---------------|
+  |08/01/2013  | $3,000|
+  |08/02/2013  | $5,700|
+  |08/03/2013  | $2,000|
+  |08/05/2013  | $4,400|
+
+Wrapping the \`Sales Amount\` metric in an IFNULL function does not make data for 08/04/2013 appear because there isn't any data for that day.
+
+The IFNULL function does not populate rows of data when the row does not exist. Instead, IFNULL forces a value to appear when the value is blank.
+
+**Example - IFNULL and arithmetic operations**
+
+The prime example of when to use IFNULL is when you are performing an arithmetic operation, and one of the values could potentially be null.
+
+Suppose you have different types of transactions: payments, refunds, and partial refunds. You have two metrics to measure payments ( \`# Payments\` ) and refunds ( \`# Refunds\` ):
+
+\`\`\`
+SELECT COUNT({attribute/transaction_id}) WHERE {attribute/transaction_type} = "Sale"
+SELECT COUNT({attribute/transaction_id}) WHERE {attribute/transaction_type} IN ("Full Refund", "Partial Refund")
+\`\`\`
+
+Now, suppose your daily analysis calculates the difference between the number of payments received and the refunds processed. The difference metric should look like the following:
+
+\`\`\`
+SELECT {metric/no_of_payments} - {metric/no_of_refunds}
+\`\`\`
+
+However, your enterprise does not process refunds every day. If no refunds are processed for a day, the above metric generates a null value, even if there are payments.
+
+If one of the values within an expression is null, the entire expression is null. Use \`IFNULL\` to preserve the computation.
+
+To solve this problem, you would wrap the expressions in the IFNULL function like the following:
+
+\`\`\`
+SELECT IFNULL({metric/no_of_payments},0) - IFNULL({metric/no_of_refunds},0)
+\`\`\`
+If a refund was not processed for the day, the calculation can still be performed.`;

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-ranking-filters.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# Using Ranking Filters\nIn this article, you will learn how to use the MAQL's TOP and BOTTOM ranking filters.\n\nSo far we have discussed two types of filters:\n\n-   Attribute filters in expressions such as the original definition of\n    Revenue:\n\n    ```\n    SELECT {metric/revenue} WHERE {label/order_status} NOT IN (\"Cancelled\", \"Returned\")\n    ```\n\n-   Numeric filters defined using submetrics such as\n\n    ```\n    SELECT {metric/revenue} WHERE (SELECT {metric/revenue} BY {label/product_id}) > 100000\n    ```\n\nWhat if you want to compute only the revenue for the top 10 highest\nselling products? Or top 10%?\n\nThis is why MAQL includes the TOP keyword (and the corresponding\nBOTTOM).\n\nLet's try to create a few metrics to see these keywords in action:\n\n**Revenue / Top 10**\n\n```\nSELECT {metric/revenue} WHERE TOP(10) OF ({metric/revenue})\n```\n\nLet's put this metric into a table together with the original Revenue\nmetric and slice it by Product. While the Revenue metrics shows Revenue\nfor each product, the cells in the `Revenue / Top 10` column are empty\nexcept for the top highest numbers. However, if you replace the Product\nattribute with Customer, the Top 10 metric gives us non-zero numbers for\nthe top 10 customers.\n\n![top 10 example](https://www.gooddata.com/developers/cloud-native/doc/maql/top-10-example.gif)\n\nThat is flexible but not exactly what you want to achieve. If you\nwant to compute Revenue from the top 10 highest selling products, you\nhave to express that you care only about top Products somewhere in our\nmetric. you can achieve that using the submetric aggregated by Product\nusing the BY keyword. Let's define our Revenue / Top 10 Products as\n\n```\nSELECT {metric/revenue} WHERE (SELECT {metric/revenue} / Top 10 BY {label/product_id}) > 0\n```\n\nAlternatively, if you do not see any use for having the separate `Revenue /\nTop 10` metric, you can delete it and define your `Revenue / Top 10 Products`\nas\n\n```\nSELECT {metric/revenue}\nWHERE (SELECT (SELECT {metric/revenue} WHERE TOP(10) OF ({metric/revenue})) BY {label/product_id}) > 0\n```\n\nDo you care about the top 10% rather than about just the top 10? Just\nadd the percent sign:\n\n```\nSELECT {metric/revenue}\nWHERE (SELECT (SELECT {metric/revenue} WHERE TOP(10%) OF ({metric/revenue})) BY {label/product_id}) > 0\n```\n\nWe will leave the BOTTOM keyword up to the kind reader as homework and\nfocus on yet another feature of the ranking metrics.";
+//# sourceMappingURL=filtering-with-ranking-filters.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-ranking-filters.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"filtering-with-ranking-filters.d.ts","sourceRoot":"","sources":["../../../../../../../src/docs/en/docs/create-metrics/maql/filters/filtering-with-ranking-filters.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,+7EAqEiC,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-ranking-filters.js

@@ -0,0 +1,71 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# Using Ranking Filters
+In this article, you will learn how to use the MAQL's TOP and BOTTOM ranking filters.
+
+So far we have discussed two types of filters:
+
+-   Attribute filters in expressions such as the original definition of
+    Revenue:
+
+    \`\`\`
+    SELECT {metric/revenue} WHERE {label/order_status} NOT IN ("Cancelled", "Returned")
+    \`\`\`
+
+-   Numeric filters defined using submetrics such as
+
+    \`\`\`
+    SELECT {metric/revenue} WHERE (SELECT {metric/revenue} BY {label/product_id}) > 100000
+    \`\`\`
+
+What if you want to compute only the revenue for the top 10 highest
+selling products? Or top 10%?
+
+This is why MAQL includes the TOP keyword (and the corresponding
+BOTTOM).
+
+Let's try to create a few metrics to see these keywords in action:
+
+**Revenue / Top 10**
+
+\`\`\`
+SELECT {metric/revenue} WHERE TOP(10) OF ({metric/revenue})
+\`\`\`
+
+Let's put this metric into a table together with the original Revenue
+metric and slice it by Product. While the Revenue metrics shows Revenue
+for each product, the cells in the \`Revenue / Top 10\` column are empty
+except for the top highest numbers. However, if you replace the Product
+attribute with Customer, the Top 10 metric gives us non-zero numbers for
+the top 10 customers.
+
+![top 10 example](https://www.gooddata.com/developers/cloud-native/doc/maql/top-10-example.gif)
+
+That is flexible but not exactly what you want to achieve. If you
+want to compute Revenue from the top 10 highest selling products, you
+have to express that you care only about top Products somewhere in our
+metric. you can achieve that using the submetric aggregated by Product
+using the BY keyword. Let's define our Revenue / Top 10 Products as
+
+\`\`\`
+SELECT {metric/revenue} WHERE (SELECT {metric/revenue} / Top 10 BY {label/product_id}) > 0
+\`\`\`
+
+Alternatively, if you do not see any use for having the separate \`Revenue /
+Top 10\` metric, you can delete it and define your \`Revenue / Top 10 Products\`
+as
+
+\`\`\`
+SELECT {metric/revenue}
+WHERE (SELECT (SELECT {metric/revenue} WHERE TOP(10) OF ({metric/revenue})) BY {label/product_id}) > 0
+\`\`\`
+
+Do you care about the top 10% rather than about just the top 10? Just
+add the percent sign:
+
+\`\`\`
+SELECT {metric/revenue}
+WHERE (SELECT (SELECT {metric/revenue} WHERE TOP(10%) OF ({metric/revenue})) BY {label/product_id}) > 0
+\`\`\`
+
+We will leave the BOTTOM keyword up to the kind reader as homework and
+focus on yet another feature of the ranking metrics.`;

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-having-clause.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# Filtering with the HAVING Clause\nUsing the HAVING filter enables you to apply filtration to a metric\nafter all containing metrics and aggregation functions have been\ncomputed.\n\nIn MAQL, the WHERE clause is used to perform basic filtration on your\ndata before it has been aggregated. In some cases, you may want to\nfilter your metric data after it has been aggregated, so that you can\nmake conditional evaluations based on the results of the computations\nwithin the metric.\n\nHAVING clause filtration is applied after all other conditions of the\nmetric have been resolved.\n\nYou cannot apply the HAVING keyword in a metric that contains a\nWHERE clause.\n\n## Syntax\n\n```\nSELECT ... HAVING ...\n```\n\nIf your metric contains multiple keywords, they must be listed in alphabetical order:\n\n```\nSELECT (...) (BY ...) (FOR ...) (WHERE...|HAVING ...) (WITH PF|WITHOUT PF)\n```\n\n### Restrictions\n\nSuppose you have created a metric containing the following: \n\n```\nSELECT SUM({fact/sales}) BY {label/date.quarter}, {attribute/product_id} HAVING {label/region} = \"West\"\n```\n\nHowever, since there is no direct relationship between Quarter and\nRegion or between Product and Region, the HAVING clause conditions are\nignored.\n\nHowever, if the HAVING clause included Quarter, Year, Product, or\nProduct Category, then the filter would be applied.\n\nA HAVING filter is only applied if the data model supports its\nevaluation.\n\n## Examples\n\n```\nSELECT SUM({fact/sales}) BY {label/date.quarter}, {attribute/product_id} HAVING {label/region} = \"West\"\n```\n\n```\nSELECT SUM({fact/amount}) BY {attribute/region}, {label/date.quarter} HAVING {label/date.year} = \"2014\"\n```\n\n```\nSELECT SUM({fact/amount}) BY {label/date.quarter} FOR PREVIOUS({label/date.quarter}) HAVING {label/date.quarter} = \"2014\" WITHOUT PARENT FILTER\n```\n\nThe last MAQL statement above returns values for amount for the quarter\nbefore this one, displaying only results from 2014. No parent filters\nare applied.";
+//# sourceMappingURL=filtering-with-the-having-clause.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-having-clause.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"filtering-with-the-having-clause.d.ts","sourceRoot":"","sources":["../../../../../../../src/docs/en/docs/create-metrics/maql/filters/filtering-with-the-having-clause.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,w+DA+DP,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-having-clause.js

@@ -0,0 +1,65 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# Filtering with the HAVING Clause
+Using the HAVING filter enables you to apply filtration to a metric
+after all containing metrics and aggregation functions have been
+computed.
+
+In MAQL, the WHERE clause is used to perform basic filtration on your
+data before it has been aggregated. In some cases, you may want to
+filter your metric data after it has been aggregated, so that you can
+make conditional evaluations based on the results of the computations
+within the metric.
+
+HAVING clause filtration is applied after all other conditions of the
+metric have been resolved.
+
+You cannot apply the HAVING keyword in a metric that contains a
+WHERE clause.
+
+## Syntax
+
+\`\`\`
+SELECT ... HAVING ...
+\`\`\`
+
+If your metric contains multiple keywords, they must be listed in alphabetical order:
+
+\`\`\`
+SELECT (...) (BY ...) (FOR ...) (WHERE...|HAVING ...) (WITH PF|WITHOUT PF)
+\`\`\`
+
+### Restrictions
+
+Suppose you have created a metric containing the following: 
+
+\`\`\`
+SELECT SUM({fact/sales}) BY {label/date.quarter}, {attribute/product_id} HAVING {label/region} = "West"
+\`\`\`
+
+However, since there is no direct relationship between Quarter and
+Region or between Product and Region, the HAVING clause conditions are
+ignored.
+
+However, if the HAVING clause included Quarter, Year, Product, or
+Product Category, then the filter would be applied.
+
+A HAVING filter is only applied if the data model supports its
+evaluation.
+
+## Examples
+
+\`\`\`
+SELECT SUM({fact/sales}) BY {label/date.quarter}, {attribute/product_id} HAVING {label/region} = "West"
+\`\`\`
+
+\`\`\`
+SELECT SUM({fact/amount}) BY {attribute/region}, {label/date.quarter} HAVING {label/date.year} = "2014"
+\`\`\`
+
+\`\`\`
+SELECT SUM({fact/amount}) BY {label/date.quarter} FOR PREVIOUS({label/date.quarter}) HAVING {label/date.quarter} = "2014" WITHOUT PARENT FILTER
+\`\`\`
+
+The last MAQL statement above returns values for amount for the quarter
+before this one, displaying only results from 2014. No parent filters
+are applied.`;

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-like-clause.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# Filtering with the LIKE Clause\nThe LIKE clause is a filtering condition designed to search\nattribute-label string values to match a specified pattern.\n\nThe LIKE clause can be used with the following criteria:\n\n-    **LIKE** - filters for the string pattern and is case sensitive.\n\n-    **ILIKE** - filters for the string pattern and is case insensitive.\n\n-    **NOT LIKE** - returns anything not defined in the string pattern\n    and is case sensitive .\n\n-    **NOT ILIKE** - returns anything not defined in the string pattern\n    and is case insensitive .\n\n**Wildcards**\n\n-   An underscore (_) matches any single character.\n\n-   A percentage sign (%) matches any string of zero or more\n    characters.\n\nTo match underscore or percent sign without matching other characters,\nthe character in the pattern must be preceded by two backslash\ncharacters (e.g. *\"\\\\%\"*).\n\n**Example**\n\n```\nSELECT SUM({metric/revenue}) WHERE {label/product_name} LIKE \"%red%\"\n```\n\nThe revenue comes from products containing \"red\" in the Product Name\nlabel of attribute Product.";
+//# sourceMappingURL=filtering-with-the-like-clause.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-like-clause.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"filtering-with-the-like-clause.d.ts","sourceRoot":"","sources":["../../../../../../../src/docs/en/docs/create-metrics/maql/filters/filtering-with-the-like-clause.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,8kCAkCQ,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-like-clause.js

@@ -0,0 +1,36 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# Filtering with the LIKE Clause
+The LIKE clause is a filtering condition designed to search
+attribute-label string values to match a specified pattern.
+
+The LIKE clause can be used with the following criteria:
+
+-    **LIKE** - filters for the string pattern and is case sensitive.
+
+-    **ILIKE** - filters for the string pattern and is case insensitive.
+
+-    **NOT LIKE** - returns anything not defined in the string pattern
+    and is case sensitive .
+
+-    **NOT ILIKE** - returns anything not defined in the string pattern
+    and is case insensitive .
+
+**Wildcards**
+
+-   An underscore (_) matches any single character.
+
+-   A percentage sign (%) matches any string of zero or more
+    characters.
+
+To match underscore or percent sign without matching other characters,
+the character in the pattern must be preceded by two backslash
+characters (e.g. *\"\\\\%\"*).
+
+**Example**
+
+\`\`\`
+SELECT SUM({metric/revenue}) WHERE {label/product_name} LIKE "%red%"
+\`\`\`
+
+The revenue comes from products containing \"red\" in the Product Name
+label of attribute Product.`;

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-where-clause.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# Filtering with the WHERE Clause\nAfter you have aggregated a fact to form the foundations of a metric,\nyou can use MAQL syntax to add filters to your metric definition.\nFilters are optional features that can be used to narrow the set of data\nfrom which a metric is computed. With logical expressions, you can also\ncombine two or more filters within a single metric definition.\n\nThe basic syntax for filters uses the word WHERE to introduce the filter\nexpression:\n\n```\nSELECT ... WHERE ...\n```\n\nThis section will explore several types of syntax for customizing metric\nfilters:\n\n-   Special operators for defining filters\n    -   Example:\n\n        ```\n        SELECT {metric/revenue} WHERE {label/date.year} = \"2006\"\n        ```\n-   Time macros for filtering for floating time periods:\n    -   Example:\n\n        ```\n        SELECT {metric/payment} WHERE {attribute/date} = THIS \u2013 1\n        ```\n-   Logical expressions for combining filters\n    -   Example:\n\n        ```\n        SELECT {metric/revenue} WHERE {label/date.year} = \"2006\" AND {label/date.month} = \"5\"\n        ```";
+//# sourceMappingURL=filtering-with-the-where-clause.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-where-clause.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"filtering-with-the-where-clause.d.ts","sourceRoot":"","sources":["../../../../../../../src/docs/en/docs/create-metrics/maql/filters/filtering-with-the-where-clause.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,omCAkCL,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/filtering-with-the-where-clause.js

@@ -0,0 +1,36 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# Filtering with the WHERE Clause
+After you have aggregated a fact to form the foundations of a metric,
+you can use MAQL syntax to add filters to your metric definition.
+Filters are optional features that can be used to narrow the set of data
+from which a metric is computed. With logical expressions, you can also
+combine two or more filters within a single metric definition.
+
+The basic syntax for filters uses the word WHERE to introduce the filter
+expression:
+
+\`\`\`
+SELECT ... WHERE ...
+\`\`\`
+
+This section will explore several types of syntax for customizing metric
+filters:
+
+-   Special operators for defining filters
+    -   Example:
+
+        \`\`\`
+        SELECT {metric/revenue} WHERE {label/date.year} = "2006"
+        \`\`\`
+-   Time macros for filtering for floating time periods:
+    -   Example:
+
+        \`\`\`
+        SELECT {metric/payment} WHERE {attribute/date} = THIS – 1
+        \`\`\`
+-   Logical expressions for combining filters
+    -   Example:
+
+        \`\`\`
+        SELECT {metric/revenue} WHERE {label/date.year} = "2006" AND {label/date.month} = "5"
+        \`\`\``;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions-except-for-attribute.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute\nThis keyword clause overrides all attributes except for those attributes\nwithin the dimension of the attribute that is specified.\n\nALL IN ALL OTHER DIMENSIONS can be abbreviated as \"All Other.\"\n\n## Syntax\n\n```\nSELECT \u2026 BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR\u2026\nSELECT metric BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute\n```\n\n## Examples\n\n```\nSELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR {attribute/date_opportunity_closed})\n```\n\nIn this example, Payment could be broken down by any date in the Date(Opportunity Closed) date dimension, such as `Month/Year(Opportunity Closed)`, `Quarter/Year(Opportunity Closed)`, or `Year(Opportunity Closed)`.";
+//# sourceMappingURL=by-all-in-all-other-dimensions-except-for-attribute.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions-except-for-attribute.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"by-all-in-all-other-dimensions-except-for-attribute.d.ts","sourceRoot":"","sources":["../../../../../../../../src/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions-except-for-attribute.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,0vBAmByM,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions-except-for-attribute.js

@@ -0,0 +1,21 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute
+This keyword clause overrides all attributes except for those attributes
+within the dimension of the attribute that is specified.
+
+ALL IN ALL OTHER DIMENSIONS can be abbreviated as \"All Other.\"
+
+## Syntax
+
+\`\`\`
+SELECT … BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR…
+SELECT metric BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR attribute
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR {attribute/date_opportunity_closed})
+\`\`\`
+
+In this example, Payment could be broken down by any date in the Date(Opportunity Closed) date dimension, such as \`Month/Year(Opportunity Closed)\`, \`Quarter/Year(Opportunity Closed)\`, or \`Year(Opportunity Closed)\`.`;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# BY ALL IN ALL OTHER DIMENSIONS\nThis clause overrides all attributes - keeping the metric from being\nbroken down at all. As a result, the associated metric will remain\naggregated at the highest possible level of aggregation across all\ndimensions.\n\nALL IN ALL OTHER DIMENSIONS can be abbreviated as \"ALL OTHER\".\n\n## Syntax\n\n```\nSELECT ... BY ALL IN ALL OTHER DIMENSIONS\nSELECT metric BY ALL IN ALL OTHER DIMENSIONS\n```\n\n## Examples\n\n```\nSELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS\nSELECT {metric/payment} / (SELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS)\n```\n\nThe second example above could be useful in a visualization that breaks data\ndown with a Month attribute. The above metric would show the percent\nshare of each month's payments relative to the sum of all payments\nacross all time and all other dimensions.";
+//# sourceMappingURL=by-all-in-all-other-dimensions.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"by-all-in-all-other-dimensions.d.ts","sourceRoot":"","sources":["../../../../../../../../src/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,k2BAyBsB,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions.js

@@ -0,0 +1,27 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# BY ALL IN ALL OTHER DIMENSIONS
+This clause overrides all attributes - keeping the metric from being
+broken down at all. As a result, the associated metric will remain
+aggregated at the highest possible level of aggregation across all
+dimensions.
+
+ALL IN ALL OTHER DIMENSIONS can be abbreviated as \"ALL OTHER\".
+
+## Syntax
+
+\`\`\`
+SELECT ... BY ALL IN ALL OTHER DIMENSIONS
+SELECT metric BY ALL IN ALL OTHER DIMENSIONS
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS
+SELECT {metric/payment} / (SELECT {metric/payment} BY ALL IN ALL OTHER DIMENSIONS)
+\`\`\`
+
+The second example above could be useful in a visualization that breaks data
+down with a Month attribute. The above metric would show the percent
+share of each month's payments relative to the sum of all payments
+across all time and all other dimensions.`;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# BY ALL\nThe BY ALL keyword is used to override a specified attribute dimension.\n\nFor example, `Date/Year(Lead Created)`, `Month/Year(Lead Created)`, `Quarter/Year\nLead Created)` all represent attributes of varying granularity within the\nsame dimension. This effectively prohibits any attribute of that\ndimension from breaking down the metric at hand.\n\n## Syntax\n\n```\nSELECT \u2026 BY ALL \u2026\nSELECT metric BY ALL attribute\nSELECT metric BY ALL attribute1, ALL attribute2\n```\n\n## Examples\n\n```\nSELECT {metric/payment} BY ALL {label/date.quarter}\nSELECT {metric/payment} / (SELECT {metric/payment} BY ALL {label/date.quarter})\nSELECT {metric/payment} / (SELECT {metric/payment} BY ALL {label/date.quarter}, ALL {attribute/industry})\n```\n\nIn the example below, the number of leads is broken down by quarter in\ncolumn 3. But in column 4, the BY keyword has been used to set an\naggregation floor at the Year level, returning annual lead values for\n2012 and 2013. Compare these values to those in the final column which\ndisplays values of a metric: `#Leads BY ALL Year`.\n\nThese values represent the total number of leads across all time - the sum of all leads\nrecorded in the entire data set.\n\n![The BY ALL Year clause serves to override all attributes from the attribute dimension to which Year belongs.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-leads.png)\n\nAlso of interest in the example above is how the `#Leads BY ALL DATE`, `#LEADS BY ALL MONTH`, and `#LEADS BY ALL YEAR` metrics all return\nidentical values. This demonstrates that the granularity of the\nattribute added to the BY ALL clause does not affect the values that are\nreturned. The attribute that follows BY ALL simply dictates that the\ndimension to which it belongs should not be able to break down the\nmetric at hand. For this reason, even if the precise granularity of the\nattribute used in the BY ALL clause doesn't matter, an attribute must\nalways be specified as a way of defining the dimension of interest.\n\nAs the BY ALL YEAR metric from the final column of the table above\nshows, BY ALL overrides other date attributes in the visualization - keeping\nthem from affecting metric values in the final column. But this does not\nmean those metric values are immune to being broken down by non-date\nattributes as well. In the example below, note how the `#Leads BY ALL\nYear` metric values **can** be broken down by an *Industry* attribute even\nif they are not affected by date attributes. (`#Leads BY ALL Year` values\nfor each industry are aggregated across all time. Notice how the\nindustry figures are identical between Q4/2012 and Q1/2012.)\n\nBY ALL YEAR only overrides the Year attribute. The metric can still be broken down by other visualization attributes like Industry.\n\n![The BY ALL Year clause doesn't prevent slicing by other attributes](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-leads-industry.jpg)\n\nIn the example above, we could also add ALL Industry to the end of our\n`#Leads BY ALL Year` metric syntax to override both the date attribute\nand industry attribute dimensions.\n\n![Both Year and Industry are overridden, so the metric is not broken down.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-overridden.jpg)";
+//# sourceMappingURL=by-all.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"by-all.d.ts","sourceRoot":"","sources":["../../../../../../../../src/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,6vGA8DyI,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all.js

@@ -0,0 +1,64 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# BY ALL
+The BY ALL keyword is used to override a specified attribute dimension.
+
+For example, \`Date/Year(Lead Created)\`, \`Month/Year(Lead Created)\`, \`Quarter/Year
+Lead Created)\` all represent attributes of varying granularity within the
+same dimension. This effectively prohibits any attribute of that
+dimension from breaking down the metric at hand.
+
+## Syntax
+
+\`\`\`
+SELECT … BY ALL …
+SELECT metric BY ALL attribute
+SELECT metric BY ALL attribute1, ALL attribute2
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT {metric/payment} BY ALL {label/date.quarter}
+SELECT {metric/payment} / (SELECT {metric/payment} BY ALL {label/date.quarter})
+SELECT {metric/payment} / (SELECT {metric/payment} BY ALL {label/date.quarter}, ALL {attribute/industry})
+\`\`\`
+
+In the example below, the number of leads is broken down by quarter in
+column 3. But in column 4, the BY keyword has been used to set an
+aggregation floor at the Year level, returning annual lead values for
+2012 and 2013. Compare these values to those in the final column which
+displays values of a metric: \`#Leads BY ALL Year\`.
+
+These values represent the total number of leads across all time - the sum of all leads
+recorded in the entire data set.
+
+![The BY ALL Year clause serves to override all attributes from the attribute dimension to which Year belongs.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-leads.png)
+
+Also of interest in the example above is how the \`#Leads BY ALL DATE\`, \`#LEADS BY ALL MONTH\`, and \`#LEADS BY ALL YEAR\` metrics all return
+identical values. This demonstrates that the granularity of the
+attribute added to the BY ALL clause does not affect the values that are
+returned. The attribute that follows BY ALL simply dictates that the
+dimension to which it belongs should not be able to break down the
+metric at hand. For this reason, even if the precise granularity of the
+attribute used in the BY ALL clause doesn't matter, an attribute must
+always be specified as a way of defining the dimension of interest.
+
+As the BY ALL YEAR metric from the final column of the table above
+shows, BY ALL overrides other date attributes in the visualization - keeping
+them from affecting metric values in the final column. But this does not
+mean those metric values are immune to being broken down by non-date
+attributes as well. In the example below, note how the \`#Leads BY ALL
+Year\` metric values **can** be broken down by an *Industry* attribute even
+if they are not affected by date attributes. (\`#Leads BY ALL Year\` values
+for each industry are aggregated across all time. Notice how the
+industry figures are identical between Q4/2012 and Q1/2012.)
+
+BY ALL YEAR only overrides the Year attribute. The metric can still be broken down by other visualization attributes like Industry.
+
+![The BY ALL Year clause doesn't prevent slicing by other attributes](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-leads-industry.jpg)
+
+In the example above, we could also add ALL Industry to the end of our
+\`#Leads BY ALL Year\` metric syntax to override both the date attribute
+and industry attribute dimensions.
+
+![Both Year and Industry are overridden, so the metric is not broken down.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-all-overridden.jpg)`;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-attribute-all-in-all-other-dimensions.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# BY attribute ALL IN ALL OTHER DIMENSIONS\nThe first part of this keyword serves a similar role as the BY\nstatement, defining an aggregation floor at the granularity level of the\nspecified attribute. But the keyword also overrides all attributes in\nall other dimensions - keeping them from having any effect on the\nmetric.\n\nALL IN ALL OTHER DIMENSIONS can be abbreviated as \"All Other.\"\n\n## Syntax\n\n```\nSELECT \u2026 BY \u2026 ALL IN ALL OTHER DIMENSIONS\nSELECT metric BY attribute ALL IN ALL OTHER DIMENSIONS\n```\n\n## Examples\n\n```\nSELECT SUM(metric/resolution_time) BY {label/date.quarter} ALL IN ALL OTHER DIMENSIONS\n```";
+//# sourceMappingURL=by-attribute-all-in-all-other-dimensions.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-attribute-all-in-all-other-dimensions.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"by-attribute-all-in-all-other-dimensions.d.ts","sourceRoot":"","sources":["../../../../../../../../src/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-attribute-all-in-all-other-dimensions.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,yoBAoBb,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-attribute-all-in-all-other-dimensions.js

@@ -0,0 +1,22 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# BY attribute ALL IN ALL OTHER DIMENSIONS
+The first part of this keyword serves a similar role as the BY
+statement, defining an aggregation floor at the granularity level of the
+specified attribute. But the keyword also overrides all attributes in
+all other dimensions - keeping them from having any effect on the
+metric.
+
+ALL IN ALL OTHER DIMENSIONS can be abbreviated as \"All Other.\"
+
+## Syntax
+
+\`\`\`
+SELECT … BY … ALL IN ALL OTHER DIMENSIONS
+SELECT metric BY attribute ALL IN ALL OTHER DIMENSIONS
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT SUM(metric/resolution_time) BY {label/date.quarter} ALL IN ALL OTHER DIMENSIONS
+\`\`\``;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "# BY\nThe BY keyword is used to set a minimum level of granularity by which a\nmetric can be broken down. BY effectively sets an **aggregation floor**,\noverriding visualization attributes that would serve to break the metric down\ninto smaller units of granularity than is specified in the BY clause.\n\n## Syntax\n\n```\nSELECT \u2026 BY \u2026\nSELECT metric BY attribute\nSELECT metric BY attribute1, attribute2\n```\n\n## Examples\n\n```\nSELECT {metric/Payment} BY {label/date.year}\nSELECT {metric/Payment} / (SELECT {metric/Payment} BY {label/date.year})\nSELECT {metric/Payment} BY {label/date.quarter}, {attribute/department}\n```\n\n## By Clauses with One Attribute\n\nThe example below shows customer support ticket resolution time by month\nand quarter. Note how the BY clause is used in the third column to\nestablish that the metric values should not be broken down by any date\nattribute smaller than `Quarter`. The effect of the BY keyword can be\nseen by comparing column 3 and column 2 cell values. Even though the\nvisualization's `Month/Year` attribute breaks visualization data in column 2 down by\nmonth, column 3 data remains at the `Quarter` level.\n\n![Customer support ticket resolution time for each month, each quarter, and the share of a quarter's resolution time that can be attributed to each month.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-tickets-table.png)\n\nColumn 4 provides an interesting use case for the BY keyword: it\ndisplays the percent share of the total resolution time in a quarter\nthat can be attributed to each month. This is found by dividing the\nmetric from column 2 by the metric from column 3 using the following\nsyntax:\n\n```\nSELECT(SELECT SUM(metric/resolution_time)) / (SELECT SUM(metric/resolution_time) BY Quarter)\n```\n\nContinuing on with this example, note what happens when we replace the\nvisualization's Month attribute with a Year attribute (with larger granularity than the metric's Quarter BY attribute). The chart below shows that the\nBY keyword no longer affects the data returned by the metric in column\n2.\n\nThe BY keyword provides a floor - or minimum aggregation level - at the\n`Quarter` level, but does not affect metric data that is aggregated at\nthe larger `Year` level of granularity.\n\n\n![The BY Quarter clause does not override visualization attributes of larger granularity. Rather, it only serves to set a minimum aggregation level.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-tickets-quarter.png)\n\n## By Clauses with Multiple Attributes\n\nThe BY clause also supports multiple attributes, including non-date\nattributes. For example, the syntax below sets an aggregation floor at\nthe Quarter and Department levels.\n\n```\nSELECT SUM({metric/payment}) BY {label/date.quarter}, {attribute/department}\n```\n\nDue to the second attribute in the clause above, sub-attributes of\n`Department` like `Product_Team` or `Employee` could be added to a\nvisualization definition, but values returned by this metric would still be\naggregated at the `Department` level.\n\n## By Clauses with Datasets\n\nYou can replace attributes with datasets in BY clauses and represent their granularity. \n\nThis provides the same result as using primary key attributes if datasets have the primary keys defined.\n\n```\nSELECT AVG( SELECT ({metric/order_amount}) BY {dataset/order_lines} )\n```\n\nThe `order_amount` metric multiplies price by quantity. \n\nThe metric described above calculates the average of `order_amount` per each record of the `order_lines` dataset.";
+//# sourceMappingURL=by.d.ts.map

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"by.d.ts","sourceRoot":"","sources":["../../../../../../../../src/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by.ts"],"names":[],"mappings":"AAEA,eAAO,MAAM,OAAO,wgHAmFkG,CAAC"}

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-attribute-filters/by.js

@@ -0,0 +1,85 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# BY
+The BY keyword is used to set a minimum level of granularity by which a
+metric can be broken down. BY effectively sets an **aggregation floor**,
+overriding visualization attributes that would serve to break the metric down
+into smaller units of granularity than is specified in the BY clause.
+
+## Syntax
+
+\`\`\`
+SELECT … BY …
+SELECT metric BY attribute
+SELECT metric BY attribute1, attribute2
+\`\`\`
+
+## Examples
+
+\`\`\`
+SELECT {metric/Payment} BY {label/date.year}
+SELECT {metric/Payment} / (SELECT {metric/Payment} BY {label/date.year})
+SELECT {metric/Payment} BY {label/date.quarter}, {attribute/department}
+\`\`\`
+
+## By Clauses with One Attribute
+
+The example below shows customer support ticket resolution time by month
+and quarter. Note how the BY clause is used in the third column to
+establish that the metric values should not be broken down by any date
+attribute smaller than \`Quarter\`. The effect of the BY keyword can be
+seen by comparing column 3 and column 2 cell values. Even though the
+visualization's \`Month/Year\` attribute breaks visualization data in column 2 down by
+month, column 3 data remains at the \`Quarter\` level.
+
+![Customer support ticket resolution time for each month, each quarter, and the share of a quarter's resolution time that can be attributed to each month.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-tickets-table.png)
+
+Column 4 provides an interesting use case for the BY keyword: it
+displays the percent share of the total resolution time in a quarter
+that can be attributed to each month. This is found by dividing the
+metric from column 2 by the metric from column 3 using the following
+syntax:
+
+\`\`\`
+SELECT(SELECT SUM(metric/resolution_time)) / (SELECT SUM(metric/resolution_time) BY Quarter)
+\`\`\`
+
+Continuing on with this example, note what happens when we replace the
+visualization's Month attribute with a Year attribute (with larger granularity than the metric's Quarter BY attribute). The chart below shows that the
+BY keyword no longer affects the data returned by the metric in column
+2.
+
+The BY keyword provides a floor - or minimum aggregation level - at the
+\`Quarter\` level, but does not affect metric data that is aggregated at
+the larger \`Year\` level of granularity.
+
+
+![The BY Quarter clause does not override visualization attributes of larger granularity. Rather, it only serves to set a minimum aggregation level.](https://www.gooddata.com/developers/cloud-native/doc/maql/by-tickets-quarter.png)
+
+## By Clauses with Multiple Attributes
+
+The BY clause also supports multiple attributes, including non-date
+attributes. For example, the syntax below sets an aggregation floor at
+the Quarter and Department levels.
+
+\`\`\`
+SELECT SUM({metric/payment}) BY {label/date.quarter}, {attribute/department}
+\`\`\`
+
+Due to the second attribute in the clause above, sub-attributes of
+\`Department\` like \`Product_Team\` or \`Employee\` could be added to a
+visualization definition, but values returned by this metric would still be
+aggregated at the \`Department\` level.
+
+## By Clauses with Datasets
+
+You can replace attributes with datasets in BY clauses and represent their granularity. 
+
+This provides the same result as using primary key attributes if datasets have the primary keys defined.
+
+\`\`\`
+SELECT AVG( SELECT ({metric/order_amount}) BY {dataset/order_lines} )
+\`\`\`
+
+The \`order_amount\` metric multiplies price by quantity. 
+
+The metric described above calculates the average of \`order_amount\` per each record of the \`order_lines\` dataset.`;

package/esm/docs/en/docs/create-metrics/maql/filters/overriding-parent/with-parent-except.d.ts

@@ -0,0 +1,2 @@
+export declare const content = "Includes all parent filters, except for any filters specified as a\ncomma-separated list of attributes.\n\nThis clause can be shortened to WITH PF EXCEPT.\n\nIn EXCEPT clauses, multiple attributes can be specified as a series of\ncomma-separated values.\n\n## Example\n\nIn the table below, you can see how the WITH PARENT\nFILTER EXCEPT keyword affects the filtered version of the visualization.\n\n\n| Definition               | Visualization Filter            | Metric Value |\n|--------------------------|--------------------------|--------------|\n| `SELECT M1`              | (none)                   | 500          |\n| `SELECT M1`              | F1: Group = X          | 350          |\n| `SELECT M1`              | F1: Group = X; F2: Priority is Y           | 250          |\n| `SELECT M1 WITH PARENT FILTER EXCEPT {attribute/priority}`  | F1: Group = X; F2: Priority is Y      | 350          |\n\nIn the above example in the fourth row, the\nWITH PARENT FILTER EXCEPT includes all parent filters in the metric,\nexcept for one: Priority. So, in this case, the Priority filter is not\napplied to the metric. The generated metric value equates to the value\ngenerated in the version in the second row.\n\n## Syntax\n\n```\nSELECT ... WITH PARENT FILTER EXCEPT Attribute1,...\n```\n\n```\nSELECT ... WITH PF EXCEPT Attribute1,...\n```";
+//# sourceMappingURL=with-parent-except.d.ts.map