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

package/esm/docs/en/docs/create-metrics/maql/time-macros.js

@@ -0,0 +1,79 @@
+// (C) 2021-2026 GoodData Corporation
+export const content = `# Time Macros
+Time macros or time macro functions are \"floating\" references to day, month, week, and other date-related attribute values, relative to the present.
+MAQL supports the following time macro functions:
+
+- THIS
+- PREVIOUS
+- NEXT
+
+These macros are useful for creating visualizations that relate to data from \"today\", \"yesterday\", \"this month\", \"next year\" etc.
+
+### "THIS" Macro
+
+THIS macro references the current value of the specified date granularity.
+
+In the following example, THIS macro is used with the day granularity, effectively meaning *this day*, or \"today\":
+
+\`\`\`
+SELECT {metric/payment} WHERE {attribute/date} = THIS(DAY)
+\`\`\`
+
+If the date granularity of the macro changes, so does the meaning of THIS. You can use following time macro granularities:
+
+- DAY
+- MONTH
+- QUARTER
+- YEAR
+- WEEK
+- WEEKOFYEAR
+- MONTHOFYEAR
+- QUARTEROFYEAR
+- DAYOFMONTH
+- DAYOFWEEK
+- DAYOFYEAR
+
+Other date granularities supported by GoodData platform (such as HOUR, MINUTE etc.) are currently not available for time macros.
+
+### Referencing past or future dates
+
+Optionally you can specify second parameter of THIS macro to reference future
+or previous time periods. For example,
+
+\`\`\`
+SELECT {metric/payment} WHERE {attribute/month} = THIS(Month, -2)
+\`\`\`
+
+computes payments of the month two months ago.
+
+To illustrate more, suppose the current date is **November 3, 2014**.
+Then following table summarizes values of THIS macro for various combinations of granularities (in rows) and period shifts (columns).
+Note that \`THIS(<granularity>, 0)\` is equivalent to \`THIS(<granularity>)\`.
+
+|  | 0 | 2 | -1 |
+| - | - | - | - |
+| Day | 11/3/2014 | 11/5/2014 |  11/2/2014 |
+| DayOfWeek | 1 (Monday) | 3 (Wednesday) | 0 (Sunday) |
+| MonthOfYear | 11 (November) | 1 (January) | 10 (October) |
+| QuarterOfYear | Q4 | Q2 | Q3 |
+| Quarter | Q4/2014 | Q2/2015 | Q3/2014 |
+
+
+Notice that if the date granularity is periodic, such as QuarterOfYear (Q1, Q2,
+Q3, Q4) or MonthOfYear (January, February, March, etc), the resulting value might roll over to the next or
+backward to the previous period.
+
+### "PREVIOUS" and "NEXT" Macros
+
+For convenience MAQL also supports shortcuts for the other two most common relative periods: previous and next.
+
+- \`PREVIOUS(<granularity>)\` is equivalent to \`THIS(<granularity>, -1)\`
+- \`NEXT(<granularity>)\` is equivalent to \`THIS(<granularity>, 1)\`
+- \`PREVIOUS(<granularity>, <shift>)\` is equivalent to \`THIS(<granularity>, - <shift>)\`
+- \`NEXT(<granularity>, <shift>)\` is equivalent to \`THIS(<granularity>, shift>)\`
+
+Example:
+
+\`\`\`
+SELECT {metric/payment} WHERE {attribute/month} = PREVIOUS(Month)
+\`\`\``;

package/esm/docs/index.d.ts

@@ -0,0 +1,82 @@
+/**
+ * IETF BCP 47 language tags for supported locales in documentation
+ *
+ * @internal
+ */
+export declare const locales: readonly ["en-us"];
+/**
+ * @internal
+ */
+export type Locale = (typeof locales)[number];
+export declare const docsIndex: {
+    readonly "en-us": {
+        readonly approximate_count: "# APPROXIMATE_COUNT\nUse APPROXIMATE_COUNT to return the approximate number of unique values for an attribute. Because the returned value is a statistical estimate and not an exact figure, this function can increase the processing speed when analyzing large datasets. You can use APPROXIMATE_COUNT anywhere you can use COUNT. The smaller the amount of data to process, the more likely that the returned results of APPROXIMATE_COUNT will match the results of COUNT. \n\n - APPROXIMATE_COUNT is available only for workspaces that use [Vertica](https://www.gooddata.com/developers/cloud-native/doc/hosted/connect-data/create-data-sources/vertica/) Data Sources.\n - APPROXIMATE_COUNT uses the Vertica default behavior for APPROXIMATE_COUNT_DISTINCT. It is not possible to use modifiers.\n - GoodData defaults to COUNT when APPROXIMATE_COUNT is unavailable in a workspace.\n\n## Syntax\n\nAPPROXIMATE_COUNT uses the following syntax:\n\n\n  |Form       |        Syntax            |                                           Example|\n  |------------------ |------------------------------------------------------------| --------------------------------------------|\n  |single parameter   |`SELECT APPROXIMATE_COUNT(attribute)`                                    |`SELECT APPROXIMATE_COUNT({attribute/order_id})`|\n  |two parameters     |`SELECT APPROXIMATE_COUNT(attribute, primary_key)`                       |`SELECT APPROXIMATE_COUNT({attribute/order_id}, {attribute/campaign_id})`|\n  |with USING         |`SELECT APPROXIMATE_COUNT(attribute) USING primary_key`   |`SELECT APPROXIMATE_COUNT({attribute/order_id}) USING {attribute/campaign_id}`|\n\n\n### Single-Parameter Version\n\nThe single-parameter version of APPROXIMATE_COUNT dynamically gets the context of\nwhere to count from the visualization it is used in.\n\n### Two-Parameter Version\n\nIn the two-parameter version, the context where to count the attribute\nis determined explicitly by the second parameter - the primary key of\nthe dataset.\n\nThe primary key is connection point between datasets. It connects the\nAPPROXIMATE_COUNT function's first parameter to the dataset in which the count is\nto take place.\n\n### Specifying APPROXIMATE_COUNT Context Resolution with USING\n\nIn a metric, USING provides a hint for which context should be used.\nThe context for the computation of APPROXIMATE COUNT may be ambiguous if there are\nmultiple fact datasets in your logical data model that relate to a counted attribute. \n\nThe following image shows a model with the fact datasets `Purchases` and `Sales` and\nhas both datasets connected to the `Store ID` and `Product ID` attributes.\n\n![model for count example](https://www.gooddata.com/developers/cloud-native/doc/maql/count-ldm-using.png)\n\nTo create a metric that resolves with a specific context, you can specify USING in your metric like in the following \nexample: `SELECT COUNT({label/inventory.productid}) USING {label/purchases.purchaseid}`. \n\nWith this example, the visualization will show the approximate number of uniquely purchased products per store \nbecause the attribute `Purchase ID` from the `Purchases` dataset is in the USING clause.\n\nWith the example model, if you build a visualization to display the approximate count of products per store with \n`SELECT COUNT({label/inventory.productid})` and slice it by Store without specifying USING, it is ambiguous whether \nthe visualization is displaying the approximate number of unique products that have been purchased by store or the\napproximate number of unique products that have been sold by the store.\n\nThe attribute in the USING clause can be any attribute which uniquely determines the correct context. For example, you\ncan also use an attribute from the `Purchase Date` dataset in the USING clause. This uses the `Purchases` dataset as \nthe context because the `Sales` dataset has no relationships to `Purchase Date`: \n`SELECT COUNT({label/inventory.productid}) USING {label/purchasedate.year}`";
+        readonly avg: "# AVG\nThe AVG function returns the average value of all numbers in the set (e.g., Salary paid). Null values are ignored.\n\n## Syntax\n\n```\nSELECT AVG(…)\nSELECT AVG(fact)\n```\n\n## Examples\n\nThe metric AVG of Payment is computed by adding all payment transactions\ntogether and dividing by the number of payment transactions:\n\n```\nSELECT AVG({fact/payment})\n```";
+        readonly count: "# COUNT\nUse COUNT to return the number of unique values for an attribute or the number of dataset records.\n - For large amounts of data where complete accuracy is not a priority, consider using APPROXIMATE_COUNT to increase the processing speed. APPROXIMATE_COUNT is available only for workspaces that use [Vertica](https://www.gooddata.com/developers/cloud-native/doc/hosted/connect-data/create-data-sources/vertica/) as a data source.\n\n## Syntax\n\nCOUNT uses the following syntax:\n\n\n  |Form       |        Syntax            |                                           Example|\n  |------------------ |------------------------------------------------------------| --------------------------------------------|\n  |single parameter   |`SELECT COUNT(attribute)`                                    |`SELECT COUNT({attribute/order_id})`|\n  |two parameters     |`SELECT COUNT(attribute, primary_key)`                       |`SELECT COUNT({attribute/order_id}, {attribute/campaign_id})`|\n  |     |`SELECT COUNT(attribute, dataset)`                       |`SELECT COUNT({attribute/order_id}, {SELECT COUNT({attribute/order_id}, {dataset/campaigns})`|\n  |with USING         |`SELECT COUNT(attribute) USING primary_key`   |`SELECT COUNT({attribute/order_id}) USING {attribute/campaign_id}`|\n  |         |`SELECT COUNT(attribute) USING dataset`   |`SELECT COUNT({attribute/order_id}) USING {dataset/campaigns}`|\n\n\n### Single-Parameter Version\n\nThe single-parameter version of COUNT dynamically gets the context of\nwhere to count from the visualization it is used in.\n\n### Two-Parameter Version\n\nIn the two-parameter version, the context where to count the attribute\nis determined explicitly by the second parameter - the primary key of\nthe dataset.\n\nThe primary key is connection point between datasets. It connects the\nCOUNT function's first parameter to the dataset in which the count is\nto take place.\n\n### Count of Dataset Records \nYou can use a dataset identifier as the first argument of COUNT as well.  The behavior of COUNT slightly changes depending on whether a primary key is defined in the dataset. \n\nIf there is a primary key, the number of unique values of the primary key attribute is returned. \n\nIf there is no primary key attribute, the count of all records (including possible duplicates) is returned.\n\n|Form       |        Syntax            |                                           Example|\n  |------------------ |------------------------------------------------------------| --------------------------------------------|\n  |single parameter   |`SELECT COUNT(dataset)`                                    |`SELECT COUNT({dataset/order_lines})`|\n\n\n### Specifying COUNT Context Resolution with USING\n\nIn a metric, USING provides a hint for which context should be used.\nThe context for the computation of COUNT may be ambiguous if there are\nmultiple fact datasets in your logical data model that relate to a counted attribute. \n\nThe following image shows a model with the fact datasets `Purchases` and `Sales` and\nhas both datasets connected to the `Store ID` and `Product ID` attributes.\n\n![model for count example](https://www.gooddata.com/developers/cloud-native/doc/maql/count-ldm-using.png)\n\nTo create a metric that resolves with a specific context, you can specify USING in your metric like in the following \nexample: `SELECT COUNT({label/inventory.productid}) USING {label/purchases.purchaseid}`. \n\nWith this example, the visualization will show the number of uniquely purchased products per store \nbecause the attribute `Purchase ID` from the `Purchases` dataset is in the USING clause.\n\nWith the example model, if you build a visualization to display the count of products per store with \n`SELECT COUNT({label/inventory.productid})` and slice it by Store without specifying USING, it is ambiguous whether \nthe visualization is displaying the number of unique products that have been purchased by store or the number of unique \nproducts that have been sold by the store.\n\nThe attribute in the USING clause can be any attribute which uniquely determines the correct context. For example, you\ncan also use an attribute from the `Purchase Date` dataset in the USING clause. This uses the `Purchases` dataset as \nthe context because the `Sales` dataset has no relationships to `Purchase Date`: \n`SELECT COUNT({label/inventory.productid}) USING {label/purchasedate.year}`";
+        readonly first: "# FIRST_VALUE\nThe `FIRST_VALUE` function returns the first value of a sequence. \n\nThe function is typically used to determine the first value of semi-additive fact when used together with sum aggregation.\n\n\n## Syntax\n\n```\nSELECT FIRST_VALUE({numeric})\n      ORDER BY {attribute/label} [ASC|DESC]\n      [WITHIN (... | CURRENT)]\n\n```\n\nThe argument of the function is a metric or a subselect defining an aggregation.\n\n> If you use facts, make sure that the fact has only a single value defined for each `ORDER BY` attribute.\n\nThe sequence is determined by the attribute in `ORDER BY`. The metric is broken down by the given attribute and the results are displayed in the ascending order by default.\n\n> To show the result in the descending order, use the DESC directive.\n>\n> `NULL` values are considered as the smallest values.\n\nIf the metric is broken down by other attributes, these attributes define a partition in which the first value is being determined. \n\nUse the `WITHIN` keyword to avoid this behavior and use the common first value for all the values of the given attributes.\n\n## Examples\n\nThe first value of a sum of semi-additive snapshots from a dataset with daily snapshots. \n\nExample of such a semi-additive snapshot can be **account balance** (values of multiple accounts can be summed up but not their daily snapshots).\n\n```\nSELECT FIRST_VALUE(SUM({fact/snapshot_value})) ORDER BY {attribute/date.day}\n```\n\nFor a more complex example, see also [LAST_VALUE](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/aggregation/last/).";
+        readonly last: "# LAST_VALUE\nThe `LAST_VALUE` function returns the last value of a sequence. \n\nThe function is typically used to determine the last value of semi-additive fact when used together with sum aggregation.\n\n## Syntax\n\n```\nSELECT LAST_VALUE({numeric})\n      ORDER BY {attribute/label} [ASC|DESC]\n      [WITHIN (... | CURRENT)]\n\n```\n\nThe argument of the function is a metric or a subselect defining an aggregation.\n\n> If you use facts, make sure that the fact has only a single value defined for each `ORDER BY` attribute.\n\nThe sequence is determined by the attribute in `ORDER BY`. The metric is broken down by the given attribute and the results are displayed in the ascending order by default.\n\n> To show the result in the descending order, use the DESC directive.\n>\n> `NULL` values are considered as the smallest values.\n\nIf the metric is broken down by other attributes, these attributes define a partition in which the last value is being determined. \n\nUse the `WITHIN` keyword to avoid this behavior and use the common last value for all the values of the given attributes.\n\n> See also [FIRST_VALUE](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/aggregation/first/) for additional information.\n\n## Examples\n\nThe last value of a sum of semi-additive snapshots from a dataset with daily snapshots. \n\nExample of such a semi-additive snapshot can be **account balance** (values of multiple accounts can be summed up but not their daily snapshots).\n\n```\nSELECT LAST_VALUE(SUM({fact/snapshot_value})) ORDER BY {attribute/date.day}\n```\n\nTo show how much your account balance has grown since the beginning of the year, you can use the following metrics and syntax:\n\n| Metric | Syntax |\n| --- | --- |\n| last_day_value | `SELECT LAST_VALUE(SUM({fact/snapshot_value})) ORDER BY {attribute/date.day}` |\n| first_day_value_in_year | `SELECT FIRST_VALUE(SUM({fact/snapshot_value})) ORDER BY {attribute/date.day} WITHIN ({attribute/date.year})` |\n| growth_to_date | `SELECT {metric/last_day_value}/{metric/first_day_value_in_year}-1` |\n\n</br>\nThe result may look as follows:\n\n| Date - Month/Year| last_day_value | first_day_value_in_year | growth_to_date |\n| --- | --- | --- | --- |\n|2022-01|1,000|1,000|0%|\n|2022-02|2,000|1,000|+100%|\n|2022-03|3,000|1,000|+200%|\n|2022-04|4,000|1,000|+300%|\n|2022-05|5,000|1,000|+400%|\n|2022-06|6,000|1,000|+500%|\n|2022-07|7,000|1,000|+600%|\n|2022-08|8,000|1,000|+700%|\n|2022-09|9,000|1,000|+800%|\n|2022-10|10,000|1,000|+900%|\n|2022-11|11,000|1,000|+1000%|\n|2022-12|12,000|1,000|+1100%|\n|2023-01|13,000|12,000|+8.3%|\n|2023-02|14,000|12,000|+16.7%|\n|2023-03|15,000|12,000|+25%|";
+        readonly max: "# MAX\n## Metrics\n\nThe MAX function returns the maximum value of all numbers in the set\n(e.g., Salary Paid).\n\n### Syntax\n\n```\nSELECT MAX(…)\nSELECT MAX(fact)\n```\n\n### Example\n\nThe MAX of the Store Sales fact is the highest sales transaction value on record:\n\n```\nSELECT MAX({fact/sales})\n```\n\n## Attributes\n\nThe MAX function can be also used to determine the maximum value of attributes with non-numeric data types (e.g. string or date attributes). \n\nThe results cannot be displayed in insights directly, but they can be used in conditional filtering, for example, to filter the last snapshot.\n\n### Syntax\n\n```\nSELECT MAX(attribute)\nSELECT MAX(attribute,primary_key)\nSELECT MAX(attribute,dataset)\nSELECT MAX(attribute) USING attribute\n```\n\nIf the attribute is referenced from multiple fact datasets, use two parameters in the MAX function. \n\nThe context where to search for maximum value of the attribute is determined by the second parameter - the primary key of the dataset or the dataset identifier. \n\nFor date attributes, use the second attribute or the USING keyword.\n\n### Examples\n\nThe sum of semi-additive snapshot values for the last of the daily snapshots.  \n\n```\nSELECT SUM({fact/snapshot_value}) \nWHERE {attribute/snapshot_date.day} =\n      (SELECT MAX({attribute/snapshot_date.day},{dataset/fact_dataset}))\n```\n\nIf the metric is broken down by other attributes and displayed as a table, the maximum value can be different for each row. \n\nTo use the maximum date for all rows, add `BY ALL OTHER` to the syntax.\n```\nSELECT SUM({fact/snapshot_value}) \nWHERE {attribute/snapshot_date.day} =\n      (SELECT MAX({attribute/snapshot_date.day},{dataset/fact_dataset}) BY ALL OTHER)\n```";
+        readonly median: "# MEDIAN\nThe MEDIAN function counts the statistical median - an order statistic\nthat gives the middle value of a sample. If the middle falls between two\nvalues, the function returns average of the two middle values. Null\nvalues are ignored.\n\nThe MEDIAN function is especially useful in cases where a small set of\noutliers could drastically skew the average if calculated as a mean.\n\n## Syntax\n\n```\nSELECT MEDIAN(…)\nMEDIAN(fact)\nMEDIAN(metric)\nMEDIAN(metric_expression)\n```\n\n## Examples\n\n```\nSELECT MEDIAN({fact/cost}) BY ALL OTHER\nSELECT MEDIAN({metric/payment}) BY {attribute/customer}\n```";
+        readonly min: "# MIN\n## Metrics\n\nThe MIN function returns the minimum value of all numbers in the set\n(e.g., Salary Paid).\n\n### Syntax\n\n```\nSELECT MIN(…)\nSELECT MIN(fact)\n```\n\n### Example\n\nThe MIN of the *Opportunity Amount* fact is the lowest opportunity\namount value on record:\n\n```\nSELECT MIN({fact/opportunity_amount})\n```\n\n## Attributes\n\nThe MIN function can be also used to determine the minimum value of attributes with non-numeric data types (e.g. string or date attributes). \n\nThe results cannot be displayed in insights directly, but they can be used in conditional filtering, for example, to filter the last snapshot.\n\n### Syntax\n\n```\nSELECT MIN(attribute)\nSELECT MIN(attribute,primary_key)\nSELECT MIN(attribute,dataset)\nSELECT MIN(attribute) USING attribute\n```\n\nIf the attribute is referenced from multiple fact datasets, use two parameters in the MIN function. \n\nThe context where to search for minimum value of the attribute is determined by the second parameter - the primary key of the dataset or the dataset identifier. \n\nFor date attributes, use the second attribute or the USING keyword.\n\n### Examples\n\nThe sum of semi-additive snapshot values for the first of the daily snapshots.  \n\n```\nSELECT SUM({fact/snapshot_value}) \nWHERE {attribute/snapshot_date.day} =\n      (SELECT MIN({attribute/snapshot_date.day},{dataset/fact_dataset}))\n```\n\n\nIf the metric is broken down by other attributes and displayed as a table, the minimum value can be different for each row. \n\nTo use the minimum date for all rows, add `BY ALL OTHER` to the syntax.\n```\nSELECT SUM({fact/snapshot_value}) \nWHERE {attribute/snapshot_date.day} =\n      (SELECT MIN({attribute/snapshot_date.day},{dataset/fact_dataset}) BY ALL OTHER)\n```";
+        readonly sum: "# SUM\nThe SUM function returns a sum of all numbers in the set (e.g., Salary\nPaid).\n\n## Syntax\n\n```\nSELECT SUM(…)\nSELECT SUM(fact)\n```\n\n## Examples\n\nThe metric defined by the SUM of the *Sales* fact would be computed by\nadding revenue earned from all individual sales transactions: \n\n```\nSELECT SUM({fact/sales})\n```";
+        readonly case: "# CASE\nCASE is a conditional statement that performs logical tests on a series\nof conditions and returns values when a condition is met. The CASE\nfunction returns a numeric result. You use CASE for complex conditional\nexpressions that contain two or more conditions.\n\nCASE is followed by WHEN/THEN keywords to specify the conditions, then\nby ELSE to specify the default return.\n\nIf no match is found, the default return expression (ELSE) is used. If\nthere is no default return and no values match, then `null` value is returned.\nAll CASE expressions conclude with the END keyword.\n\n## CASE and Multidimensionality\n\nBefore proceeding to the CASE syntax samples, as a user you have to\nunderstand that usage guidelines for CASE in the MAQL environment are based on multidimensionality. Understanding multidimensionality is crucial to\nensure your CASE metrics return correct results (see [MAQL and Multidimensionality](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/maql-and-multidimensionality/)).\n\n-   CASE does not work with the base data level.\n-   Instead, the condition is evaluated on the aggregation dimension.\n-   All WHENs are evaluated independently but all based on a single\n    dimension (the aggregation dimension mentioned in the previous\n    point).\n\nIn most common scenarios you should follow this rule:\n\n-   Always put the CASE statement inside (not outside) an aggregation (SUM) container.\n\nSee examples below.\n\n## CASE Syntax\n\nCASE can be used in the following two syntax forms:\n\n\n| Form             |  Syntax         | Example|\n|-----------------|------------------|--------------|\n| No aggregation   |  `SELECT CASE WHEN condition1 THEN outcome1, WHEN condition2 THEN outcome 2 ELSE outcome3 END`        |       `SELECT CASE WHEN {attribute/activity_type} IN (\"email\", \"meeting\") THEN 1, WHEN {attribute/activity_type} IN (\"phone_call\") THEN 2 ELSE 0 END`|\n|With aggregation   |`SELECT SUM (SELECT CASE WHEN condition1 THEN outcome1, WHEN condition2 THEN outcome2 ELSE outcome3 END)`  | `SELECT SUM (SELECT CASE WHEN {attribute/activity_type} IN (\"email\", \"meeting\") THEN {fact/amount} ELSE {fact/loss} END)` |\n\nUsing the aggregation container ensures that the CASE conditions are\ncomputed on the correct dimension and returns relevant results.\n\n## How to Use CASE Correctly\n\nAs noted above, we advise you to use CASE inside aggregation containers.\n\nHere is an example of incorrect use of CASE in the following logical\ndata model. For the sake brevity, only one CASE condition is used.\n\n![An example of incorrect use of CASE ](https://www.gooddata.com/developers/cloud-native/doc/maql/case.png)\n\nIf you want to slice the following metric with **Campaign Category**,\nthe visualization would not compute because the WHEN conditions are not\nrelated to visualization dimensionality:\n\n```\nSELECT CASE WHEN {fact/customer_state} IN (\"AR\", \"NY\") THEN SUM ({fact/price}) ELSE SUM({fact/price} * {fact/quantity}) END\n```\n\nOn the other hand, the same metric when sliced by attribute **Customer\nID** (instead of **Campaign Category**) is valid. That is because the\nslicing attribute (**Customer ID**) is directly related to the CASE\ncondition attribute (Customer State).\n\nIf you need to slice by unrelated attribute, put the CASE statement\ninside the SUM aggregation instead:\n\n```\nSELECT SUM(SELECT CASE WHEN {attribute/customer_state} IN (\"AR\", \"NY\") THEN {fact/price} ELSE {fact/price} * {fact/quantity} END)\n```";
+        readonly "if-then-else": "# IF THEN ELSE\nIF THEN ELSE construct is a simplified version of CASE statement: \n\n```\nSELECT IF condition THEN expression ELSE expression END\n```\nis equivalent to\n```\nSELECT CASE WHEN condition THEN expression ELSE expression END\n```\n\nFor the detailed discussion of the semantics see [CASE statement](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/conditionals/case/).\n\n## Syntax\n\n```\nSELECT IF … THEN … ELSE … END\nSELECT IF condition THEN number ELSE number END\nSELECT IF condition THEN arithmetic_operation ELSE arithmetic_operation END\n```\n\n## Examples\n\n```\nSELECT IF SUM({fact/amount})>= AVG({fact/amount}) THEN 10 ELSE 0 END\nSELECT IF SUM({fact/duration}) - AVG({fact/duration}) > 2000  THEN 0 ELSE 1 END\nSELECT IF AVG({fact/probability}) > 0.5 THEN SUM({fact/amount}) * 10 ELSE SUM({fact/amount}) / 10 END\n```";
+        readonly ifnull: "# IFNULL\nIFNULL statement allows you to control replacement of missing values that are returned by an expression.\n\nIf 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.\n\nIFNULL 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. \n\n## Syntax\n\n```\nSELECT IFNULL(…,…)\nSELECT IFNULL(metric, replacement_value)\n```\n\n## Examples\n\n```\nSELECT IFNULL(SUM({fact/amount}), 0)\nSELECT IFNULL(SUM({metric/fb_cost} + {metric/tw_cost}), 0)\nSELECT IFNULL(SUM({fact/amount}) + 100, 1)\n```\n\nSupported replacement values include constants, but not other metric expressions.\n\n## IFNULL Best Practices\n\nThe IFNULL function is used to replace missing values in fact tables and to replace values when a computation generates a null value.\n\nA null value is not the same thing as zero (0). A null value means one of the following:\n\n-   no entry has been made\n-   the value is unknown\n\nThe IFNULL function can be useful for handling or trapping values that are null, which can confuse your analysis.\n\nHowever, the function should not be overused, as it can add significant computing time and consume workspace computational bandwidth.\n\nDo 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.\n\nWrapping a metric in the IFNULL statement enables operations where one of the values is null. The syntax for this statement looks like the following:\n\n```\nSELECT IFNULL(metric_reference, replacement_value)\n```\n\nThe IFNULL function can be applied to facts, too.\n\n```\nSELECT IFNULL(fact_name, replacement_value)\n```\n\n**Example - Data with a missing line item**\n\nAn IFNULL does not mean that there is a blank or missing line item.\n\nSuppose your data looks like the following:\n\n  |Date      |   Sales Amounts|\n  |------------| ---------------|\n  |08/01/2013  | $3,000|\n  |08/02/2013  | $5,700|\n  |08/03/2013  | $2,000|\n  |08/05/2013  | $4,400|\n\nWrapping 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.\n\nThe 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.\n\n**Example - IFNULL and arithmetic operations**\n\nThe prime example of when to use IFNULL is when you are performing an arithmetic operation, and one of the values could potentially be null.\n\nSuppose you have different types of transactions: payments, refunds, and partial refunds. You have two metrics to measure payments ( `# Payments` ) and refunds ( `# Refunds` ):\n\n```\nSELECT COUNT({attribute/transaction_id}) WHERE {attribute/transaction_type} = \"Sale\"\nSELECT COUNT({attribute/transaction_id}) WHERE {attribute/transaction_type} IN (\"Full Refund\", \"Partial Refund\")\n```\n\nNow, 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:\n\n```\nSELECT {metric/no_of_payments} - {metric/no_of_refunds}\n```\n\nHowever, 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.\n\nIf one of the values within an expression is null, the entire expression is null. Use `IFNULL` to preserve the computation.\n\nTo solve this problem, you would wrap the expressions in the IFNULL function like the following:\n\n```\nSELECT IFNULL({metric/no_of_payments},0) - IFNULL({metric/no_of_refunds},0)\n```\nIf a refund was not processed for the day, the calculation can still be performed.";
+        readonly "filtering-with-ranking-filters": "# 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.";
+        readonly "filtering-with-the-having-clause": "# 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.";
+        readonly "filtering-with-the-like-clause": "# 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.";
+        readonly "filtering-with-the-where-clause": "# 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 – 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        ```";
+        readonly "by-all-in-all-other-dimensions-except-for-attribute": "# 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 … BY ALL IN ALL OTHER DIMENSIONS EXCEPT FOR…\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)`.";
+        readonly "by-all-in-all-other-dimensions": "# 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.";
+        readonly "by-all": "# 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 … BY ALL …\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)";
+        readonly "by-attribute-all-in-all-other-dimensions": "# 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 … BY … 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```";
+        readonly by: "# 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 … BY …\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.";
+        readonly "with-parent-except": "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```";
+        readonly "with-parent-filter": "Applies all parent filters to the metric. All parent filters specified\nin visualizations, dashboards, and any metrics in which this metric is nested\nare applied to the calculation.\n\nThis clause can be shortened to WITH PF.\n\nThe WITH PARENT keyword is applied by default when other visualization filters\nare not present.\n\n## Example\n\nIn the table below, you can see how the WITH PARENT FILTER clause\naffects 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 (SELECT M1 WITH PARENT FILTER) WHERE Group = Y`            | F1: Group = X | null         |\n\nIn the third row above, the definition includes a nested metric in which\nparent filters are forced to be included from inside the nested metric.\n\n-   In the parent metric is the filter Group = Y.\n-   At the visualization level, the filter is Group = X.\n-   The WITH PARENT FILTER keyword means that all parent filters are\n    applied to the metric. During evaluation, both Group = X and Group =\n    Y are applied to the data as a logical AND. Since a data element may\n    be associated with a single attribute value, there are no data\n    elements that match both filters, and the result set is null.\n\n## Syntax\n\n```\nSELECT ... WITH PARENT FILTER\n```\n\n```\nSELECT ... WITH PF\n```";
+        readonly "without-parent-except": "Remove parent filters, except for any filters specified as a comma-separated list of attributes.\n\nThis clause can be shortened to WITHOUT PF EXCEPT.\n\nIn EXCEPT clauses, multiple attributes may be specified as a series of\ncomma-separated values.\n\nExcepted attribute filters are applied to the specified attribute and to\nall attributes of coarser granularity in the hierarchy. For example, in\nthe hierarchy State-County-City, the values of the attribute City do not\ngroup the values of County, but County groups City because County has coarser granularity than City. So, if City is excepted, County and State\nare excepted too. If you apply the exception to the State attribute, it\nis the only attribute filter that is excepted.\n\n## Syntax\n\n```\nSELECT ... WITHOUT PARENT FILTER EXCEPT Attribute1,...\n```\n\n```\nSELECT ... WITHOUT PF EXCEPT Attribute1,...\n```\n\n## Example 1\n\nIn the table below, you can see how the WITHOUT PARENT FILTER EXCEPT\nkeyword works with the State-County-City hierarchy.\n\n\n| Definition                          | visualization Filter    | Metric Value |\n|-------------------------------------|------------------|--------------|\n| `SELECT M1`                         | (none)           | 1000         |\n| `SELECT M1`                         |  F1: County = X | 600          |\n| `SELECT M1 WITHOUT PF`              |  F1: County = X | 1000         |\n| `SELECT M1 WITHOUT PF EXCEPT City`  |  F1: County = X | 600          |\n| `SELECT M1 WITHOUT PF EXCEPT State` |  F1: County = X | 1000         |\n| `SELECT M1 WITHOUT PF EXCEPT State` |  F1: State = Y  | 550          |\n\n\n-   In the above example in the third row, the WITHOUT PARENT FILTER\n    removes all parent filters from the metric, so COUNTY = X is not\n    applied. The returned results match the unfiltered version of the\n    metric in the first row.\n-   In the fourth row, City is excepted. Since County has a coarser grain than City, the parent visualization filter (County = X) is applied.\n-   In the fifth row, the excepted filter is State. However, the visualization\n    filter is at the County attribute level, which is finer than State.\n    Therefore, the filter is not applied, and the results match the\n    unfiltered version in the first row.\n-   In the fifth row, the excepted filter is State, which matches the\n    visualization filter. So, the results are filtered.\n\n## Example 2\n\nIn the table below, you can see how the WITHOUT 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 =            | 250          |\n|                          | X; F2: Priority is Y    |              |\n| `SELECT M1 WITHOUT PARENT FILTER EXCEPT Group`   |  F1: Group = X; F2: Priority is Y           | 350          |\n\n\nIn the above example in the fourth row, the\nWITHOUT PARENT FILTER EXCEPT removes all parent filters from the metric,\nexcept for one: Group, so the Priority filter is not applied to the\nmetric. The generated metric value equates to the value generated in the\nversion in the second row.\n\n\n## Example 3\n\n  |Definition                                                                |  visualization Filter|\n  |---------------------------------------------------------------------------|---------------|\n  |`SELECT (SELECT M1 WITHOUT PF EXCEPT Date) WHERE (SELECT M2 BY Date) > Y`  | Group = X |\n\n\n-   M2 is filtered by group.\n-   M1 is not filtered by group, only by the numeric range filter in the\n    `WHERE` part.\n\n## Example 4\n\n| Definition                                          | Visualization Filter |\n|-----------------------------------------------------|---------------|\n| `SELECT (SELECT M1 WITHOUT PF EXCEPT Date) WHERE (SELECT M2 BY Date) > Y`    | Group = X  Date = Z   |\n\n-   M2 is filtered by group, date.\n-   M1 is filtered by date and the numeric range in the `WHERE` part.";
+        readonly "without-parent-filter": "Removes parent filters from being applied to the metric. All parent\nfilters specified in visualization, dashboards, and any metrics in which this\nmetric is nested are ignored.\n\nThis clause can be shortened to WITHOUT PF.\n\n**Example**\n\nIn the table below, you can see how the WITHOUT PARENT FILTER clause\naffects 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 WITHOUT PARENT FILTER` |  F1: Group = X | 500          |\n\n\nSince the metric in the third row removes the parent filter in the\nvisualization, the returned value matches the calculation when no visualization filter\nis applied in the first row.\n\n## Syntax\n\n```\nSELECT ... WITHOUT PARENT FILTER\n```\n\n```\nSELECT ... WITHOUT PF\n```";
+        readonly and: "# AND\nAND logical operator works in the following way:\n\n-   If both expressions are true (e.g. not FALSE and not NULL), then the\n    result is true.\n-   In all other cases, the result is false.\n\nIf you combine filters using AND, both filters are applied when\ncomputing the metric.\n\n## Examples:\n\n```\nSELECT {metric/payment} WHERE {label/date.year} = \"2006\" AND {label/date.month} = \"5\"\n```\n\nWhile OR combines filters in a way that allows more data to pass through\nvisualization computations, AND restricts, or limits, the amount of data that\nis used in computations.\n\nConsider the case where our metric has a filter that serves to include\nall data from 2006 as well as data from the first four months of 2007.\nAdding an additional AND clause onto the metric definition limits the\ndata that is used in the metric's computations because now there are\nmore conditions than before that data must meet in order to be included in computations.\n\nIn the following example, payments must come from 2006 or the first four\nmonths of 2007 to be included in metric computations. They must also be\ngreater than $10,000.\n\n```\nSELECT SUM({metric/payment}) WHERE ({label/date.year} = \"2006\" OR {label/date.month} IN (\"2007-01\", \"2007-02\", \"2007-03\", \"2007-04\")) AND {metric/payment} > 10000\n```\n\nPayment values that come from 2006 or the first four months of 2007 but\nare less than 10,000 will be excluded.";
+        readonly not: "# NOT\nNOT is a logical operator that negates the filter it precedes.\n\nIf you specify a filter and precede it with NOT, then everything that is\nspecified by the filter is excluded from the computation.\n\n**Example:**\n\n```\nSELECT {metric/profit} WHERE NOT ({label/date_ordered.year} = \"2006\" AND {label/date_ordered.month} = \"5\")\n```";
+        readonly or: "# OR\nOR logical operator works in the following way:\n\n-   If either expression is true, then the result is true.\n-   If both expressions are false, then the result is false.\n\n## Examples\n\nIn the following example, all metric values associated with the years 2006 and 2005 will be returned.\n\n```\nSELECT {metric/payment} WHERE {label/date_ordered.year} = \"2006\" OR {label/date_ordered.year} = \"2005\"\n```\n\n`OR` can also be used to combine two different types of filters. Consider\nthe case where you want to return the total of all payments from the\nyear 2006 and the first four months of 2007:\n\n```\nSELECT SUM({metric/payment}) WHERE {label/date_ordered.year} = \"2006\" OR {label/date_ordered.month} IN (\"2007-01\", \"2007-02\", \"2007-03\", \"2007-04\")\n```";
+        readonly "maql-and-multidimensionality": "# MAQL and Multidimensionality\nMultidimensionality is a fundamental principle of GoodData's MAQL (Multi-Dimension Analytical Query Language).\n\nMultidimensional modeling works with the concepts of facts and dimensions meaning that MAQL metrics are context aware.\n\nMetrics are sliced by dimension context that does not need to be specified in the MAQL expressions themselves. This multidimensional capability is one of the features that sets MAQL apart from SQL.\n\n## Examples of Multidimensionality\n\nIn this section, we will use several examples to show you how MAQL works with dimensionality.\n\n### Example 1\n\nIn this example, we created a SUM metric to display *amount sold* of a particular product.\n\n```\nSELECT SUM({fact/amount})\n```\n\nYou can apply additional *dimensions* (in this case *Product* and *Year*) to this simple metric to break down the metric:\n\n\n  |Metric       | Dimensionality |  What it returns (business meaning)|\n  |-------------| ---------------- |--------------------------------------------|\n  |Amount Sold   |(empty)        |  total all-time sales (1 row)|\n  |Amount Sold   |Product        |  all-time sales for each sold product|\n  |Amount Sold   |Product, Year   | sales for each existing year and product combination|\n\n### Example 2\n\n```\nSELECT SUM({fact/amount}) WHERE SUM({fact/amount}) > 25\n```\n\nThe dimensionality of the result and dimensionality of the filter are the same and defined by the dimensionality of the visualization.\n\n\n  |Metric            |Dimensionality   |What it returns (business meaning)|\n  |----------------- |---------------- |---------------------------------------------|\n  |Amount Sold 25+   |(empty)          |Total sales of everything every  time (if the total is >25).|\n  |Amount Sold 25+   |Product          |Total sales of each product if sales for that product is >25.|\n  |Amount Sold 25+   |Product, Year    |Sales of each product each year if at least 25 pieces of that product were sold within that year.|\n\n### Example 3\n\n```\nSELECT SUM({fact/amount}) \n    WHERE (SELECT SUM({fact/quantity}) BY {attribute/product} ALL OTHER) > 25\n```\n\nThe dimensionality of the main (result) metric is different from dimensionality of the filtering metric. The dimensionality of the filtering metric is locked to Product.\n\n\n  |Metric            |Dimensionality   |What it returns (business meaning)|\n  |----------------- |---------------- |---------------------------------------------|\n  |Amount Sold 25+   |(empty)          |Total sales of products with more than 25 sold items.|\n  |Amount Sold 25+  | Product          |Total sales of each product with more than 25 sold items.|\n  |Amount Sold 25+  | Product, Year    |Sales of each product and year for products with more than 25 sold items.|";
+        readonly abs: "# ABS\nThe absolute value function (ABS) returns an absolute value of a number\n(e.g., Revenue) as a positive number:\n\n-   positive inputs will remain unchanged\n-   negative inputs will be rendered positive\n\n## Syntax\n\n```\nSELECT ABS(…)\nSELECT ABS(number)\nSELECT ABS(metric)\n```\n\n## Examples\n\n```\nSELECT ABS(-5) returns the value \"5\"\nSELECT ABS(10) returns the value \"10\"\nSELECT ABS(({metric/total_amount})-(SELECT {metric/total_amount} WITHOUT PF))\n```";
+        readonly "arithmetic-operations": "# Arithmetic Operations\nPredefined metrics can be manipulated with any basic arithmetic\noperation: addition (+), subtraction (-), multiplication (*), and\ndivision (/).\n\nBy using numerical variables, you can also add dynamic values into your arithmetic operations.\n\n## Adding, Subtracting, Multiplying, and Dividing\n\nAdd, subtract, multiply, or divide predefined metrics.\n\n## Syntax\n\n```\nSELECT metric1 + metric2\nSELECT metric1 - metric2\nSELECT metric1 * metric2\nSELECT metric1 / metric2\n```\n\n## Examples\n\n```\nSELECT {metric/expenses} + {metric/salary}\nSELECT {metric/revenue} - {metric/cost}\nSELECT {metric/profit} * 0.03\nSELECT {metric/new_revenue} / {metric/revenue_last_year}\n```";
+        readonly ceiling: "# CEILING\nThe CEILING function rounds an input value to the nearest integer that\nis greater than it.\n\n## Syntax\n\n```\nSELECT CEILING(…)\nCEILING(constant)\nCEILING(fact)\nCEILING(metric)\nCEILING(metric_expression)\n```\n\n## Examples\n\n```\nSELECT CEILING(12.2) = 13\nSELECT CEILING(12.7) = 13\n```";
+        readonly exp: "# EXP\nThe exponential function EXP returns *e* raised to the power of a number\n(e.g., Annual rate).\n\nAs the inverse of the LN(*n*) function, EXP(*n*) returns the value of\nthe constant e, 2.71828182845904, raised to the power of the positive\nreal number, n.\n\nEXP( ) takes as arguments any numeric data, including metrics, metrics\nexpressions, and constants.\n\n## Syntax\n\n```\nEXP(…)\nEXP(number)\n```\n\n## Examples\n\n```\nSELECT EXP(10)\nSELECT EXP(1/12)\nSELECT EXP(1.5)\nSELECT EXP(SUM({fact/amount}))\n```";
+        readonly floor: "# FLOOR\nThe FLOOR function rounds an input value to the nearest integer that is\nless than it.\n\n## Syntax\n\n```\nSELECT FLOOR(…)\nFLOOR(constant)\nFLOOR(fact)\nFLOOR(metric)\nFLOOR(metric_expression)\n```\n\n## Examples\n\n```\nSELECT FLOOR(12.2) = 12\nSELECT FLOOR(12.7) = 12\n```";
+        readonly greatest: "# GREATEST\nThe GREATEST function identifies the highest value from a selection of\nfacts or metrics within one row.\n\n## Syntax\n\n```\nSELECT GREATEST(…, …, …)\nSELECT GREATEST(fact, fact)\nSELECT GREATEST(metric, metric)\nSELECT GREATEST(fact, metric, metric, fact)\n```";
+        readonly least: "# LEAST\nThe LEAST function identifies the lowest value from a selection of facts\nor metrics within one row.\n\n## Syntax\n\n```\nSELECT LEAST(…, …, …)\nSELECT LEAST(fact, fact)\nSELECT LEAST(metric, metric)\nSELECT LEAST(fact, metric, metric, fact)\n```";
+        readonly ln: "# LN\nThe LN function returns the natural logarithm of a number with base e,\nthe constant equal to 2.71828182845904. The LN function returns NULL if\nnumber is less than or equal to 0.\n\nThe LN function has the following format:\n\n```\nLN(n)\n```\n\n-   where *n* is greater than 0\n\nA natural logarithm LN(n) is the inverse of the EXP( ) function and\ntakes as arguments any numeric data, including metrics, metrics\nexpressions, and constants.\n\n## Syntax\n\n```\n SELECT LN(…)\nSELECT LN(number)\n```\n\n## Examples\n\n```\nSELECT LN(10)\nSELECT LN(1/12)\nSELECT LN(1.5)\nSELECT LN(SUM({fact/amount}))\n```";
+        readonly log: "# LOG\nThe LOG function returns the logarithm of a number for the given base\nspecified in second parameter of the LOG function. If the base value is\nomitted, base 10 is used.\n\nThe LOG function has the following format:\n\n```\nLOG(n,b)\n```\n\n-   *n* is any positive value\n-   *b* is base, *b* is any positive value other than 0 or 1\n\n## Syntax\n\n```\nSELECT LOG(…)  \nSELECT SQRT(number, base)\n```\n\n## Examples\n\n```\nSELECT LOG(10, 1/12)\nSELECT LOG(SUM({fact/amount}), 2)\nSELECT LOG({metric/amount_max} * 400, {metric/amount_Max})\n```";
+        readonly power: "# POWER\nThe POWER function returns a number raised to the base specified as the\nsecond parameter of the POWER function (e.g., Interest rate, Revenue).\nComplex and undefined results are replaced with NULL.\n\nThe POWER function has the following format:\n\n```\nPOWER(n, b)\n```\n\nThe base *n* and the exponent *b* accept any numeric data, including\nmetrics, metric expressions, and constants.\n\nFor fractional exponent (b) values, using fractions (for example, 1/2)\nrather than decimals (for example, 0.5) improves performance.\n\n## Syntax\n\n```\nPOWER(…,…)\nPOWER(number, power)\n```\n\n## Examples\n\n```\nSELECT POWER(10, 1/12)\nSELECT POWER(SUM({fact/amount}), 2)\nSELECT POWER(1, SUM({fact/amount}))\nSELECT POWER({metric/total_amount} * (1/2), {metric/total_amount})\n```";
+        readonly round: "# ROUND\nThe ROUND() function rounds a fact or metric to the number of decimal\nplaces specified in the second parameter. If the second parameter is not\nspecified, then the function rounds to the nearest integer.\n\nThe input value is rounded to an integer (by default) or to a defined\nnumber of decimal points. This function allows metric builds to retain\nexact levels of precision throughout a set of calculations.\n\n-   The first input value can be any constant, fact, metric, or metric\n    expression.\n-   The optional second parameter defines the number of decimal points\n    to which the function applies rounding. This parameter should be an\n    integer, although real numbers are supported for input.\n\n## Syntax\n\n```\nSELECT ROUND(…)\nROUND(fact)\nROUND(metric)\nROUND(metric_expression)\nROUND(input, number_of_decimal_places)\n```\n\n## Examples\n\n```\nSELECT ROUND(12.2) = 12\nSELECT ROUND(12.7) = 13\nSELECT ROUND(12.257,2) = 12.26\nSELECT ROUND (12.257,-1) = 10\n```";
+        readonly sign: "# SIGN\nThe signum (SIGN) function returns a number or metric input as one of\nthe following three values:\n\n-   -1 if the number is negative\n-   0 if the number is zero\n-   1 if the number is positive\n\nThe SIGN function follows the rule: \n\n```\nSIGN(number_input) = (number_input)/(abs(number_input))\n```\n\n## Syntax\n\n```\nSELECT SIGN(…)\nSELECT SIGN(number)\nSELECT SIGN(metric)\n```\n\n## Examples\n\n```\nSELECT SIGN(-3) returns the value -1\nSELECT SIGN(3) returns the value 1\nSELECT SIGN(0) returns the value 0\n```";
+        readonly sqrt: "# SQRT\nThe square root function (SQRT) returns a square root of a number (e.g.,\nRevenue). If the number is negative, SQRT returns NULL.\n\n## Syntax\n\n```\nSELECT SQRT(…)\nSELECT SQRT(constant)\nSELECT SQRT(metric)\n```\n\n## Examples\n\n```\nSELECT SQRT(25)\n```\n\nreturns the value \"5\"\n\n```\nSELECT SQRT(33.6)\n```\n\nreturns the value \"5.796550698\"\n\n```\nSELECT SQRT(SELECT SUM({fact/sales}))\n```\n\nreturns the square root of a Total Sales metric.";
+        readonly trunc: "# TRUNC\nThe TRUNC functions truncates a number based on the number of decimal\nplaces specified in the second parameter.\n\nBy default, the TRUNC() function allows you to remove all digits to the\nright of the decimal point without applying rounding. If a second\noptional parameter is added to the TRUNC() function, it defines the\nnumber of digits to the right of the decimal point at which truncation\nis applied. Negative values are supported for the second parameter.\n\n-   The first input value can be any constant, fact, metric, or metric\n    expression.\n-   The optional second parameter defines the number of decimal points\n    at which the remaining digits are removed. This parameter should be\n    an integer, although real numbers are supported for input.\n\n## Syntax\n\n```\nSELECT TRUNC(…)\nTRUNC(constant)\nTRUNC(fact)\nTRUNC(metric)\nTRUNC(metric_expression)\nTRUNC(input, number_of_decimal_places)\n```\n\n## Examples\n\n```\nSELECT TRUNC(12.2) = 12\nSELECT TRUNC(12.7) = 12\nSELECT TRUNC(12.257,2) = 12.25\nSELECT TRUNC(1255.257,-2) = 1200\n```";
+        readonly percentile: "# PERCENTILE\nThe PERCENTILE( ) function returns the specified percentile out of a set of values. This could be useful for establishing a threshold of\nacceptance, such as for candidates who score above the 90th percentile\non a certification exam, or rewarding sales reps in the top percentile\nwith regard to deals won in the past year.\n\n**Formats:**\n\n```\nPERCENTILE(numeric, k)\n```\n\n-   where *numeric* is a fact or metric\n-   where *k* is a value between 0 and 1 representing the percentile you\n    want returned specified as a decimal. k accepts constants as inputs.\n    Numeric values must be expressed in the following format: 0.xx\n-   For metric expressions, you should compute percentiles using syntax\n    similar to the following:\n\n    ```\n    SELECT PERCENTILE((SELECT SUM([fact]) BY [attribute]),0.25)\n    ```\n\n    ```\n    PERCENTILE(numeric, k%)\n    ```\n\n-   where *numeric* is a fact or metric\n-   where *k%* is a number between 0 and 100 representing the percentile\n    you want returned. k accepts constants as inputs, followed by\n    percent signs as inputs.\n-   For metric expressions, you should compute percentiles using syntax\n    similar to the following: \n\n    ```\n    SELECT PERCENTILE((SELECT SUM([fact]) BY [attribute]),25%)\n    ```\n\n## Syntax\n\n```\nSELECT PERCENTILE(…) [ASC|DESC] [BY(…)]\nSELECT PERCENTILE(metric, decimal)\nSELECT PERCENTILE(metric, percentage)\nSELECT PERCENTILE(fact, decimal)\nSELECT PERCENTILE(fact, percentage)\nSELECT PERCENTILE((SELECT SUM([metric]) BY [attribute]), decimal)\nSELECT PERCENTILE((SELECT SUM([metric]) BY [attribute]), percentage)\n```\n\n## Examples\n\n```\nSELECT PERCENTILE({metric/Amount}, 0.75)\nSELECT PERCENTILE({metric/Amount}, 75%)\n```";
+        readonly "rank-variations": "# Rank Variations\nMAQL includes the following ranking functions that sequentially rank all values in a visualization.\n\n\nThe following ranking functions differ from the TOP(n) and\nBOTTOM(n) filters which filter only for a specified number of top or\nbottom values (such as the top five or bottom five sales reps).\n\n\n| Function | Definition                                   |\n|--------------|------------------------------------------------------|\n| RANK         | Assigns a rank to each value in a set of values, leaving gaps between rows of duplicate values (ties) within the set. If any values within a set are the same (tied), the next rank following the tie is  skipped, resulting in **non-consecutive ranking**.   |\n| DENSE_RANK   | Assigns a rank to each value in a set of values, leaving no gaps between rows of duplicate values (ties) within the set. If any values within a set are the same (tied), the next rank following the tie is not skipped and the **ranking remains           consecutive**.                                       |\n| ROW_NUMBER   | Assigns a unique row number, starting from 1, to  every row within a set of values, regardless of duplicate values (ties) within the set.  |\n| PERCENT_RANK | In a set of values, calculates the number of values that are less than the current value, minus 1, divided by the total number of values in the set, minus 1. The first value in any set has a PERCENT_RANK of zero. *  (relative rank of the current value - 1) / (number of values in the set - 1)*   |\n| CUME_DIST    | In a set of values, calculates the number of values that are less than or equal to the current value  (inclusive), divided by the total number of values in the set (cumulative distribution). ( *relative rank of the current value) / (number of values in the set* |\n\nFor more information about the WITHIN clause used in the following\nexamples, see [WITHIN Clause](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/within-clause/).\n\n## RANK and DENSE_RANK\n\nThough similar, the RANK and DENSE_RANK functions differ in the way each\nranks the first row that follows rows of duplicate values.\n\nIn the following illustration, see how the output of RANK skips ranks\n(leaves a gap), whereas DENSE_RANK does not skip ranks (leaves no gap).\n\n![Comparison of RANK and DENSE_RANK](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-dense-rank.png)\n\n-   **RANK** identifies Crystal Powers as the fourth-highest ranking\n    Sales Rep in terms of number of wins in Telecom, Midwest.\n\n    ```\n    SELECT RANK ({metric/no_of_wins}) DESC WITHIN({attribute/region}, {attribute/vertical})\n    ```\n\n-   **DENSE_RANK** identifies Crystal Powers as the Sales Rep with the\n    second-highest number of wins in Telecom, Midwest.\n\n    ```\n    SELECT DENSE_RANK ({metric/no_of_wins}) DESC WITHIN({attribute/region}, {attribute/vertical})\n    ```\n\n## ROW_NUMBER\n\nThe ROW_NUMBER function assigns a unique number to every row in a set,\nregardless of duplicate values within the set.\n\n```\nSELECT ROW_NUMBER({metric/no_of_wins}) DESC WITHIN ({attribute/region}, {attribute/vertical})\n```\n\nThe following illustration shows how ROW_NUMBER can be used with the\nWITHIN clause (see [WITHIN Clause](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/within-clause/) to\nreturn unique row numbers for several subgroups in a visualization. The\npresence of duplicate values (ties) in the Number of Wins column has no\neffect on ROW_NUMBER. \n\n![ROW_NUMBER](https://www.gooddata.com/developers/cloud-native/doc/maql/row-numbers.png)\n\n## CUME_DIST and PERCENT_RANK\n\nThe CUME_DIST and PERCENT_RANK functions are very similar.\n\nThe following statements clarify how they differ.\n\n-   **CUME_DIST** (cumulative distribution) returns a number greater\n    than 0 and up to and including 1 which represents the relative\n    position of the value in the specified row within a group\n    of *N* rows. In the following figure, the CUME_DIST calculation\n    shows that 75% of sales reps in Financial, Midwest have Number of\n    Wins that are less than or equal to those of Franklin Vic.\n\n    ```\n    SELECT CUME_DIST ({metric/no_of_wins}) WITHIN({attribute/region}, {attribute/vertical})\n    ```\n\n-   **PERCENT_RANK** returns a number from 0 to 1 (inclusive) which\n    represents the relative position of the specified row, minus 1,\n    within a group of *N* rows, minus 1. In the following figure, the\n    PERCENT_RANK calculation shows that Franklin Vic is at the 67%\n    percentile in terms of total Number of Wins in his group.\n\n    ```\n    SELECT PERCENT_RANK ({metric/no_of_wins}) WITHIN({attribute/region}, {attribute/vertical})\n    ```\n\n![Comparison of CUME_DIST and PERCENT_RANK](https://www.gooddata.com/developers/cloud-native/doc/maql/cume-dist-percent-rank.png)";
+        readonly "where-top-or-bottom-in": "# TOP or BOTTOM(n) IN\nWHERE TOP|BOTTOM IN is a ranking filter. It limits the inputs into a\nmetric's computations to those values that are the top or bottom *n*\nrankings according to the ranking criteria that you specify. This filter\nsupports the percent parameters *n%*.\n\nWhen you are using filters with a percentage (such as `TOP(20%)`), the\nnumber of the selected items is always rounded **up**.\n\nFor example, you want to select 20% of 21 items, and each item has a\ndistinct value of the metric that it is ranked by. The result is going\nto be 5, because 20% of 21 is 4.2, and it gets rounded up to 5.\n\n## Syntax\n\n```\nSELECT … WHERE TOP(…) IN … WITHIN …\nSELECT metric1 WHERE TOP(n) IN (SELECT metric2 BY attribute1, attribute2...) WITHIN (...)\n```\n\nHere, `metric1` represents the metric the value of which is actually returned.\nThe value returned depends on which values are included in its\ncomputations. These inputs are determined by the filtering criteria\nstatement that follows the IN keyword in parentheses.\n\nThe attributes that follow BY are those that will be ranked according to their `metric2` values. Whichever attribute values are associated with\n`metric2` values that fall in the TOP(n) or BOTTOM(n) are then included\nin `metric1` computations - determining the final output.\n\nThe syntax for this type of rank filtering requires the SELECT keyword\nbefore the metric following the IN keyword.\n\n## Examples\n\n```\nSELECT {metric/no_of_tickets} WHERE TOP(5) IN (SELECT {metric/no_of_tickets} 2 BY {attribute/assignee}) WITHIN ({attribute/ticket_group}, all other)\n```\n\nThis example returns TOP(#) assignees by EACH group. \n\n```\nSELECT {metric/Amount} WHERE TOP(5) IN (SELECT {metric/avg_won} BY {attribute/product})\n```\n\nMAQL also supports using the OF keyword following the TOP|BOTTOM ranking\nfilter. This changes the way the metric is interpreted by the query\nengine. With OF you can carry out rankings by more than one metric.\nLikewise, the ranking metric is interpreted as a submetric, rather than\na subreport (as is the case for TOP|BOTTOM in conjunction with the IN\nkeyword).\n\nSee also [TOP or BOTTOM(n) OF](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/where-top-or-bottom-of/).";
+        readonly "where-top-or-bottom-of": "# TOP or BOTTOM(n) OF\nSimilar to [WHERE TOP or BOTTOM(n) IN](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/where-top-or-bottom-in/), WHERE TOP or\nBOTTOM OF can serve as a filter that limits the values included in the\nmetric's computations. Using the OF keyword (rather than IN) allows\nranking of more than one metric and interprets the ranking metric as a sub-metric.\n\nThis filter supports percent parameters: *n%*.\n\nWhen you are using filters with a percentage (such as `TOP(20%)`), the\nnumber of the selected items is always rounded **up**.\n\nFor example, you want to select 20% of 21 items, and each item has a\ndistinct value of the metric that it is ranked by. The result is going\nto be 5, because 20% of 21 is 4.2, and it gets rounded up to 5.\n\n## Syntax\n\n```\nSELECT … WHERE TOP(…) OF … [WITHIN …]\nSELECT  metric1  WHERE [TOP|BOTTOM](n) OF ( metric2 , ...)\nSELECT  metric1  WHERE [TOP|BOTTOM](n) OF ( metric2 , ...) WITHIN ( ... )\n```\n\n## Examples\n\n```\nSELECT {metric/amount}  WHERE TOP(5%) OF ({metric/Amount}) AND {label/product} = \"Explorer\"\n```";
+        readonly "within-clause": "# WITHIN Clause\nYou can add variations of the WITHIN clause to any supported [Rank Variations](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/rank-variations/). This syntax lets you rank\nvalues within subgroups defined by a visualization's attribute values.\nSubgroup ranking is useful, for example, if you want to rank the top\nsales reps (in terms of amount won) within each sales region.\n\n## Ranking functions without WITHIN\n\nWhen you use a ranking function without an accompanying WITHIN clause\n(for example, `SELECT RANK({metric/avg_won})`), the function sequentially ranks\nall metric values across the rows in a visualization. The output is identical\nto `RANK(...) WITHIN(ALL IN ALL OTHER DIMENSIONS)`, as displayed below.\n\n```\nSELECT RANK ({metric/amount_won})\n```\n\n![RANK without the WITHIN clause](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-without-within.png)\n\n## Ranking functions with WITHIN\n\nWhen you use ranking functions with an accompanying WITHIN clause, any\nnumber of parameter formulations are possible, resulting in different\noutputs.\n\n```\nWITHIN (attribute1, attribute2, ...)\n```\n\nRanks metric values within one or more subgroups defined by the\ninsight's attributes.\n\n```\nSELECT RANK ({metric/{amount_won}) DESC WITHIN ({attribute/vertical}, {attribute/region})\n```\n\n![WITHIN (Region,Vertical)](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-within.png )\n\n## WITHIN (ALL ATTRIBUTE)\n\nRanks metric values within one or more subgroups defined by all visualization\nattributes **other than** the attribute specified in the metric (and any\nother attributes in the same dataset as the attribute specified in the\nmetric).\n\nIf the ranking metric is a stand-alone metric, then it will rank as\ndescribed in [Rank Variations](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/ranking/rank-variations/).\n\n```\nSELECT RANK ({metric/{amount_won}) DESC WITHIN (ALL {attribute/vertical})\n```\n\nFor example, if Vertical, Region, and Sales Rep attributes are included\nin the visualization, the above metric ranks metric values sequentially by\nRegion and Sales Rep, but not by Vertical.\n\n\n![WITHIN (ALL Vertical)](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-within-all.png )\n\nNotice that if you remove Vertical from the visualization, the\nranking of Amount Won remains the same as before because the WITHIN ALL\nclause omits Vertical from the rankings.\n\nRanking remains the same when the Vertical attribute is removed from the visualization.\n\n![Rank the same](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-the-same.png)\n\n\n## WITHIN (ALL OTHER EXCEPT ATTRIBUTE)\n\nRanks metric values within one or more subgroups defined by the\nattribute specified in the metric (or any other attributes in the same\ndataset as the attribute specified in the metric), but **overrides** all\nother visualization attributes.\n\n```\nSELECT RANK ({metric/{amount_won}) DESC WITHIN (ALL OTHER EXCEPT {attribute/vertical})\n```\n\nIf Vertical and Region attributes are included in the visualization, the above\nmetric ranks Amount Won sequentially by Vertical, but not by Region.\n\n![WITHIN (ALL Vertical), Vertical removed from the visualization](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-within-removed.png )\n\n## WITHIN (CURRENT)\n\nRanks metric values within current visualization's dimensionality, as\nspecified by the visualization's attributes, where every row of the visualization is\nhandled as a separate group and thus each value is ranked '1'. \n\n```\nSELECT RANK ({metric/{amount_won}) DESC WITHIN (CURRENT)\n```\n\n![WITHIN (CURRENT)](https://www.gooddata.com/developers/cloud-native/doc/maql/rank-within-current.png )\n\nAn exception to the above would occur if you used WITHIN (CURRENT) with\nthe PERCENT_RANK function. That combination would return the percentage\nof metric values that are less than the current value, which is\nnecessarily zero in a single-value \"group.\"";
+        readonly "relational-operators": "# Relational Operators\nRelational operators can be used with facts, metrics, or date labels to\ndefine filter conditions on a metric.\n\n## Syntax\n\n```\nSELECT … WHERE … (<|>|=|!=|<>|BETWEEN) …\nSELECT metric WHERE fact1 < fact2\nSELECT metric WHERE fact1 < number\nSELECT metric1 WHERE metric2 > number\nSELECT metric WHERE date_label > date_value\nSELECT metric WHERE date1_label < date2_label\nSELECT metric WHERE attribute = attribute_value\nSELECT metric WHERE attribute <> attribute_value\nSELECT metric WHERE label IN (label_value1, label_value2)\nSELECT metric WHERE label NOT IN (label_value1, label_value2)\nSELECT metric WHERE fact BETWEEN number AND number\nSELECT metric WHERE date_label BETWEEN date_value1 AND date_value2\nSELECT metric WHERE fact NOT BETWEEN number AND metric\nSELECT metric WHERE attribute = NULL\nSELECT metric WHERE attribute <> NULL\nSELECT metric WHERE label IN (label_value1, label_value2, NULL)\nSELECT metric WHERE label NOT IN (label_value1, label_value2, NULL)\n```\n\n## Examples\n\n```\nSELECT {metric/number of transactions} WHERE {metric/total_amount} > 10000\nSELECT {metric/number_of_transactions} WHERE {metric/amount} > 6 AND {metric/amount} <= 20\nSELECT {metric/profit} WHERE {label/date_ordered.monthYear} < \"2007-05\"\nSELECT {metric/profit} WHERE {label/date_ordered.year} > \"2007\"\nSELECT {metric/profit} WHERE {label/date_ordered.date} <= \"2010-12-22\"\nSELECT {metric/profit} WHERE {label/date_ordered.week} < {label/date_shipped.week}\nSELECT {metric/payment} WHERE {label/country} = \"US\"\nSELECT {metric/payment} WHERE {label/date_ordered.week} = {label/date_shipped.week}\nSELECT {metric/payment} WHERE {label/country} <> \"US\"\nSELECT {metric/payment} WHERE {label/region} IN (\"America\", \"EU\")\nSELECT {metric/payment} WHERE {label/region} NOT IN (\"America\", \"EU\")\nSELECT {metric/payment} WHERE {label/date.quarter} BETWEEN THIS - 5 AND THIS\nSELECT {metric/payment} WHERE {fact/cost} BETWEEN 100 AND 200\nSELECT {metric/payment} WHERE {fact/cost} BETWEEN 100 AND {metric/highest_cost}\nSELECT {metric/payment} WHERE {label/country} = NULL\nSELECT {metric/payment} WHERE {label/country} <> NULL\nSELECT {metric/payment} WHERE {label/region} IN (\"America\", \"EU\", NULL)\nSELECT {metric/payment} WHERE {label/region} NOT IN (\"America\", \"EU\", NULL)\n```\n>A comparison of attribute values with NULL using MAQL relational operators translates to semantics of ``IS NULL``/ ``IS NOT NULL`` operators in SQL.";
+        readonly "rolling-window": "# Rolling Window\nUse the ROWS BETWEEN keyword to specify a rolling window over which\nrunning total functions (for example RUNAVG) are computed.\n\nRunning total functions such as RUNSUM, RUNAVG, RUNMIN and RUNMAX can be\nspecified with rolling window or a shifted boundary. An example could be\na moving average used with time series data to smooth out short-term\nfluctuations and highlight longer-term trends or cycles.\n\nROWS BETWEEN does not currently support the COUNT or APPROXIMATE_COUNT function.\n\n## Syntax\n\n```\nSELECT (RUNNING TOTAL)(...) ROWS BETWEEN (...) AND (...)\nSELECT RUNAVG (...) ROWS BETWEEN (…) AND (…)\n```\n\n## Examples\n\n**In the context of Date**\n\nDefine a moving average\n\n```\nSELECT RUNAVG (Revenue) ROWS BETWEEN 5 PRECEDING AND CURRENT ROW\n```\n\nReturn Year-to-Date (YTD) for Revenue:\n\n```\nSELECT RUNSUM (Revenue) WITHIN Year (Opp. Close) ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW\n```\n\nDefine five days preceding and the current date:\n\n```\n SELECT RUNAVG({metric}) ROWS BETWEEN 5 PRECEDING AND CURRENT ROW\n```\n\n```\nSELECT RUNAVG({metric}) ROWS BETWEEN 5 PRECEDING AND 1 PRECEDING\nSELECT RUNAVG({metric}) ROWS BETWEEN 5 PRECEDING AND 1 FOLLOWING\n```\n\nDisplay year to date - the same result as without specifying ROWS BETWEEN statement:\n\n```\nSELECT RUNSUM({metric/m}) WITHIN {attribute/year} ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW\n```\n\nDefine year to yesterday:\n\n```\nSELECT RUNSUM({metric}/m) WITHIN {attribute/year} ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING ROW\n```\n\n**In the context of Month**\n\nDefine the last twelve months:\n\n```\nSELECT RUNSUM({metric/m}) ROWS BETWEEN 13 PRECEDING AND 1 PRECEDING\n```\n\nDefine everything before the current month:\n\n```\n SELECT RUNAVG({metric/m}) WITHIN {attribute/year} ROWS BETWEEN UNBOUNDED PRECEDING AND 1 PRECEDING\n```";
+        readonly "running-total-statistical-functions": "# Running Total Statistical Functions\nRunning Total Statistical Functions calculate the standard deviation or\nvariance using all values up to the current date for a fact or metric.\nFunctions are available for standard deviation, variance, and versions\nof those functions for populations. See [Standard Deviation Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/standard-deviation-functions/) and [Variance Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/variance-functions/).\n\nSuppose you are tracking daily production for your enterprise throughout\nthe month in a simple visualization tracking daily Units. You can use the\nRUNAVG and RUNSTDEV statistical functions to track the reliability of\nestimates as the month begins to close:\n\n\n| Date      |   Units  | Running Avg Daily Units |  Running StDev |\n| ------------ | ------- | ------------------------- | --------------- |\n| 06/02/2014|  50| 50.00|  (blank value) |\n| 06/03/2014|  60| 55.00|  7.07 |\n| 06/04/2014|  70| 60.00|  10.00 |\n| 06/05/2014|  50| 57.50|  9.57 |\n| 06/06/2014|  60| 58.00|  8.37 |\n| 06/09/2014|  80| 61.67|  11.69 |\n| 06/10/2014|  50| 60.00|  11.55 |\n| 06/11/2014|  70| 61.25|  11.26 |\n| 06/12/2014|  60| 61.11|  10.54 |\n| 06/13/2014|  80| 63.00|  11.60 |\n\n\nRunning total metrics can be broken down by two or more date attributes\nfrom the same date dimension. Non-date attributes are not supported.\n\n## Syntax\n\n```\nSELECT RUNSTDEV(...)\nSELECT RUNSTDEVP(...)\nSELECT RUNVAR(...)\nSELECT RUNVARP(...)\nSELECT RUNSTDEV(...) WITHIN (...)\n```\n\nThe value for WITHIN must be a date attribute.\n\n```\nSELECT RUNSTDEV(...) WITHIN (ALL OTHER)\n```\n\n## Examples\n\n```\nSELECT RUNVAR({fact/sales})\nSELECT RUNSTDEVP({metric/leads}) WHERE {label/date_ordered.year} = THIS\nSELECT RUNVARP({metric/returns}) WHERE {metric/amount} > 500000\nSELECT RUNSTDEV({metric/opportunities}) WITHIN ({label/date_ordered.quarter_year})\n```";
+        readonly "running-totals-for-core-functions": "# Running Totals for Core Functions\nRunning Totals for Core Functions take the running sum, average,\nminimum, or maximum of a project fact or metric. In a table broken down\nby a date attribute, the running total value on any given day would be\ncalculated by aggregating values from all prior days along with that of\nthe current day.\n\nRunning total metrics can be broken down by two or more date attributes\nfrom the same date dimension. Non-date attributes are not supported.\n\n## Syntax\n\n```\nSELECT RUNSUM(...)\nSELECT RUNAVG(...)\nSELECT RUNMIN(...)\nSELECT RUNMAX(...)\nSELECT RUNSUM(...) WITHIN (...)\n```\n\nThe value for WITHIN must be a date attribute.\n\n```\nSELECT RUNSUM(...) WITHIN (ALL OTHER)\n```\n\n## Examples\n\n```\nSELECT RUNSUM({fact/sales})\nSELECT RUNSUM({fact/sales}) WITHIN({label/date.week})\nSELECT RUNSUM({fact/sales}) WITHIN({label/date.week}) BY {label/date}, {attribute/region}\nSELECT RUNMIN({fact/probability}) WHERE {label/date.year} = THIS AND {metric/amount} > 500000\nSELECT RUNMAX({fact/opportunity}) BY {label/date.quarter_year}\nSELECT RUNMAX({fact/sales}) WITHIN ({label/date.year}) WITHOUT PARENT FILTER\n```";
+        readonly correl: "# CORREL\nCorrelation indicates the degree of association between two sets of\nvalues. The CORREL function returns correlation coefficient that varies\nbetween -1 and 1.\n\n-   A value of 1 indicates that as X increases, Y always increases.\n-   A value of -1 indicates that as X increases, Y always decreases.\n-   A value of 0 indicates that there is no correlation; values for X\n    cannot be used as predictors for values of Y.\n\nCorrelation coefficient is measured by calculating the covariance of the\ntwo sets of values, which measures how they vary with each other. This\nmeasure is then divided by the product of the standard deviations of\neach set of values. See [Covariance Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/covariance-functions/) and [Standard Deviation Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/standard-deviation-functions/).\n\nCorrelation coefficient is a component calculation of the Least-Squares\nmethod of linear regression. See [Least-Squares Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/least-squares-functions/).\n\nCORREL function has the form `CORREL (numeric1,numeric2)` where\n*numeric1* and *numeric2* are facts or metrics.\n\n![Equation - Correlation Coefficient](https://www.gooddata.com/developers/cloud-native/doc/maql/correl.png)\n\nWhen this equation is broken down into its component parts, it becomes\nthe following:\n\n![Equation - Correlation Coefficient decomposed](https://www.gooddata.com/developers/cloud-native/doc/maql/correl-coef.png)\n\nFor CORREL to work, metrics and facts must be associated with the same\ndataset or the same level of granularity.\n\n## Syntax\n\n```\nSELECT CORREL(…)\nSELECT CORREL(metric1, metric2)\nSELECT CORREL(metric1, fact2)\nSELECT CORREL(fact1, fact2)\n```\n\n## Examples\n\n```\nSELECT CORREL({metric/production_volume}, {metric/rate_of_defects})\nSELECT CORREL({metric/gross_tonnage}, {metric/gross_profit})\n```";
+        readonly "covariance-functions": "# Covariance Functions\nCovariance functions return the statistical covariance - how much two\nsets of values change together based on a sample of the population\n(COVAR), or based on a biased population (COVARP).\n\nCovariance measures how two sets of values vary together. This\nelementary function is used as a building block for some of the\ntwo-dimensional statistical functions used in linear regression, as it\ndescribes collectively how the two sets of values vary around their mean\nvalues.\n\n-   `COVAR (*numeric1*, *numeric2*)`\n\n    ![Equation -Covariance](https://www.gooddata.com/developers/cloud-native/doc/maql/covar.png)\n\n    -   where *numeric1* and *numeric2* are facts or metrics\n    -   Computes the product of variance from mean for each value of *x* and *y*. These values are summed and then divided by *n*.\n    -   Use for sets of values that are only a sample of the total (biased) population.\n\n-   `COVARP (*numeric1*, *numeric2*)`\n\n    ![Equation - Covariance for Populations](https://www.gooddata.com/developers/cloud-native/doc/maql/covarp.png)\n\n    -   where *numeric1* and *numeric2* are facts or metrics\n    -   Use COVARP for calculating covariances when the numeric values are the entire population of values.\n    -   Use for sets of values that include the entire (unbiased) population, use COVARP.\n\n## Syntax\n\n```\nSELECT COVAR(…)\nSELECT COVAR(metric1, metric2)\nSELECT COVAR(fact1, metric2)\nSELECT COVAR(fact1, fact2)\nSELECT COVARP(metric1, metric2)\nSELECT COVARP(fact1, metric2)\nSELECT COVARP(fact1, fact2)\n```\n\n## Examples\n\n```\nSELECT COVAR({metric/total_cost_of_inputs}, {metric/gross_margin})\nSELECT COVARP({fact/height}, {fact/height})\n```";
+        readonly "least-squares-functions": "# Least-Squares Functions\nThe **least-squares method** of linear regression attempts to fit a\nlinear regression trend line as closely as possible. This line has the\nsmallest possible value for the sum of the squares of the errors between\nthe predicted value of the line and the actual two-dimensional data\npoints.\n\nIn the following diagram, the least-squares linear regression plots a\nline through the set of points that minimizes the sum of the squares of\nthe error factors.\n\n![Least-Squares linear regression diagram](https://www.gooddata.com/developers/cloud-native/doc/maql/least-squares-linear-regression.png)\n\nThe actual data points are calculated using the following equation:\n\n![Least-squares data points](https://www.gooddata.com/developers/cloud-native/doc/maql/least-squares-data-points.png)\n\nUse the R-squared function (RSQ) that returns square of the correlation\ncoefficient to measure how well the linear regression expresses the\nvariability of the Y values around their mean.\n\n-   `RSQ (*numeric1*, *numeric2*)`\n    -   where *numeric1* and *numeric2* are facts or metrics\n    -   Computes the R-squared value for the two sets of numeric values.\n        Also known as the **coefficient of determination**, R-squared\n        ranges between 0 and 1, with a value of 1 indicating that the\n        model explains all variability in the dependent variables data.\n\n        R-squared does not determine if there is bias in the estimates.\n\n## Syntax\n\n```\nSELECT RSQ(metric1, metric2)\nSELECT RSQ(fact1, metric2)\nSELECT RSQ(fact1, fact2)\n```\n\n## Examples\n\n```\nSELECT RSQ({metric/count_of_defects}, {metric/production_volume})\n```";
+        readonly "standard-deviation-functions": "# Standard Deviation Functions\nStandard deviation function return the statistical standard deviation of\nall values in the set based on a sample of the population (STDEV), or\nbased on a biased population (STDEVP).\n\nStandard deviation is useful for measuring variance within a data set\nand, in application, confidence in statistical results. For example, in\nfinance, standard deviation can measure the potential deviation from\nexpected return rate, measuring the volatility of the investment.\nDepending on the number of values in the sample set, you should use\neither of the following metrics.\n\n-   `STDEV (*numeric*)`, also known as the **corrected standard deviation**\n\n    ![Equation - Standard Deviation](https://www.gooddata.com/developers/cloud-native/doc/maql/stdev.png)\n    -   where *numeric* is a fact or metric\n    -   Computes the sum of squared differences from the mean for *n*\n        values divided by a sample size factor. If the input values are\n        a sample of the total (biased) population, the divisor is *(n -\n        1)* sample size, which is used in the STDEV function.\n\n    -   This value is the **variance**. See [Variance Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/variance-functions/). The square root of the above value represents the standard deviation.\n\n        If individual values are used as inputs, STDEV, generates a null\n        value. In these cases, use STDEVP instead.\n\n-   `STDEVP (*numeric*)`, also known as the **uncorrected standard deviation**.\n\n    ![Equation - Standard Deviation for Populations](https://www.gooddata.com/developers/cloud-native/doc/maql/stdevp.png )\n\n    -   where *numeric* is a fact or metric\n    -   Computes square root of the sum of squared differences from the mean for *n* values divided by *n*\n    -   Use STDEVP for calculating standard deviations if the input set\n        contains the entire (unbiased) population of values. The\n        deviation for a single value is zero.\n\n## Syntax\n\n```\nSELECT STDEV(…)\nSELECT STDEV(metric)\nSELECT STDEVP(fact)\n```\n\n## Examples\n\n```\nSELECT STDEV({metric/internal_rate_of_return})\nSELECT STDEVP({metric/gross_weight})\n```\n\n## Using Standard Deviation\n\nYou can use standard deviation to create ranges as other metrics.\nSuppose you have a standard deviation metric (StDev Transaction Amt):\n\n### Example 1: +1 Std.\n\n```\nSELECT {metric/avg_transaction_amt} + {metric/stdev_transaction_amt}\n```\n\n### Example 2: +2 Std.\n\n```\nSELECT {metric/avg_transaction_amt} + ({metric/stdev_transaction_amt} * 2)\n```\n\n### Example 3: -1 Std.\n\n```\nSELECT {metric/avg_transaction_amt} + ({metric/stdev_transaction_amt} * -1)\n```\n\n### Example 4: -2 Std.\n\n```\nSELECT {metric/avg_transaction_amt} + ({metric/stdev_transaction_amt} * -2)\n```\n\n### Sample Chart\n\nUsing the examples above, you can create a combo chart that shows all\nindividual transactions (X axis) and where they fall within bands of\n+2/-2 standard deviations (Y axis).\n\n![Transaction amounts compared to standard deviations](https://www.gooddata.com/developers/cloud-native/doc/maql/stdev-transaction-accounts.png)";
+        readonly "variance-functions": "# Variance Functions\nReturns the statistical variance - how far a set of values is spread out based on a sample of the population (VAR), or based on a biased population (VARP). Variance is non-negative, zero indicates that all values are identical.\n\nVariance computation is used to build standard deviation and other statistical functions.\n\nTo measure spread, variance calculates the mean of all values in the\nsample. For each input value in the set, the difference of the value\nfrom the mean is computed, and this difference is squared. All of the\nsquares are added together, and then divided by a sample size factor,\ndepending on the function you are using.\n\n-   Values for variance are non-negative. A value of 0 indicates that\n    there is no variance among the values; all values are identical.\n-   The square root of variance is the standard deviation. See [Standard Deviation Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/standard-deviation-functions/).\n-   Covariance measures how two sets of values change together. See\n    [Covariance Functions](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/statistic/covariance-functions/).\n\nThe spread is measured for a sample of the (biased) population (VAR) or\nfor the entire (unbiased) population (VARP).\n\n-   For a sample of the population, use the VAR function, which divides\n    the sum of squares by the number of values in the same size (N-1):\n\n    ![Equation - Variance](https://www.gooddata.com/developers/cloud-native/doc/maql/var.png)\n    -   `VAR (*numeric*)`\n        -   where *numeric* is a fact or metric\n        -   Computes the sum of squared differences from the mean for\n            *n* values divided by *n-1*\n\n-   If the set of values is the entire population of values, use the\n    VARP function, which divides the sum of squares by N:\n\n    ![Equation - Variance for Populations](https://www.gooddata.com/developers/cloud-native/doc/maql/var.png)\n\n    -   `VARP (*numeric*)``\n        -   where *numeric* is a fact or metric\n        -   Computes the sum of squared differences from the mean for\n            *n* values divided by *n*]\n\n## Syntax\n\n```\nSELECT VAR(…)\nSELECT VAR(metric)\nSELECT VARP(fact)\n```\n\n## Examples\n\n```\nSELECT VAR({metric/internal_rate_of_return})\nSELECT VARP({metric/gross_weight})\n```";
+        readonly "datetime-add": "# DATETIME_ADD\nThe `DATETIME_ADD` function adds a specified amount of intervals based on the granularity. \n\n## Syntax\n\n```\nSELECT … WHERE DATETIME_ADD(time_attribute, amount) >= time_attribute\nSELECT … WHERE DATETIME_ADD(time_attribute, granularity, amount) >= time_attribute\n```\n\n**Time attribute** can have the following formats:\n- Timestamp: ` {label/date.day}`\n- Date and time macro: `THIS(DAY)`\n- Strings: `\"2022\"` \n\nThe strings must be in the following formats: \n\n`\"YYYY-MM-DD HH24:MI\"` for minutes, `\"YYYY-MM-DD HH24\"` for hours, `\"YYYY-MM-DD\"` for days, `\"YYYY-MM\"` for months, `\"YYYY-WW\"` for weeks, and `\"YYYY\"` for years.\n\n**Amount** is an integer and specifies the amount of intervals of the given granularity.\n\n**Granularity** can be one of the following:\n* `MINUTE`\n* `HOUR`\n* `DAY`\n* `WEEK`\n* `MONTH`\n* `YEAR`\n\n* If the time attribute is a string, you must specify the granularity.\n* The granularity of the time attribute and the specified granularity in the function may be different.\n* If you do not specify the granularity, the granularity of the time attribute is used.\n\n## Examples\n\nReturn the number of loans that was returned in the last three days:\n\n```\nSELECT COUNT({label/l_loankey}) WHERE {label/l_returned.day} >= DATETIME_ADD({label/l_to.day}, -2)\n```\n\nReturn the number of loans from the 20th week of 2022:\n\n```\nSELECT COUNT({label/l_loankey}) WHERE {label/l_from.day} >= DATETIME_ADD(\"2022-01\", WEEK, 19) \n```\n\nReturn the sum of the shipping prices in the 7 days before the last returned loan.\n\n```\nSELECT SUM({fact/l_shippingprice}) WHERE {label/l_returned.day} >= DATETIME_ADD(MAX({label/l_returned.day}, {dataset/loan}), -7) \n```";
+        readonly "datetime-diff": "# DATETIME_DIFF\nThe `DATETIME_DIFF` function calculates the difference between two timestamps or dates. The resulting number is the difference between the two specified timestamps/dates based on the granularity. \n\nThe function can be used, for example, to calculate the duration of your business processes.\n\n## Syntax\n\n```\nSELECT DATETIME_DIFF(time_attribute1, time_attribute2)\nSELECT DATETIME_DIFF(time_attribute1, time_attribute2, granularity)\nSELECT … WHERE DATETIME_DIFF(time_attribute1, time_attribute2) > 5\n```\n**Time attributes** can have the following formats:\n- Timestamp: ` {label/date.day}`\n- Date and time macro: `THIS(DAY)`\n- Strings: `\"2022\"` \n\n* The strings must be in the following formats: `\"YYYY-MM-DD HH24:MI\"` for minutes, `\"YYYY-MM-DD HH24\"` for hours, `\"YYYY-MM-DD\"` for days, `\"YYYY-MM\"` for months, `\"YYYY-WW\"` for weeks, and `\"YYYY\"` for years..\n* Use max one string as time attribute.\n* Strings must have the same granularity as the second time attribute.\n\n\n**Granularity** is optional and can be one of the following:\n* `MINUTE`\n* `HOUR`\n* `DAY`\n* `WEEK`\n* `MONTH`\n* `YEAR`\n\n* If the time attribute is in the `date` format, you cannot use the `MINUTE` or `HOUR` granularity.\n* If you do not specify the granularity, the greater granularity of the two date attributes is used.\n* If you specify the granularity, the two attributes must have the same or lower granularity.\n\n\n## Examples\n\nTo count the difference between two dates without specifying the granularity (the granularity is taken from the attributes):\n\n```\nSELECT DATETIME_DIFF({label/l_from.day}, {label/l_to.day})\n```\n\nDifference in days between two time attributes with hour granularity:\n\n```\nSELECT DATETIME_DIFF({label/l_from.hour}, {label/l_to.hour}, DAY)\n```\n\nFilter data where the duration is greater than the specified amount:\n\n```\nSELECT COUNT({dataset/item}) WHERE DATETIME_DIFF({label/i_decommisioned.day}, THIS(DAY)) > 10\n```";
+        readonly "time-macros": "# Time Macros\nTime macros or time macro functions are \"floating\" references to day, month, week, and other date-related attribute values, relative to the present.\nMAQL supports the following time macro functions:\n\n- THIS\n- PREVIOUS\n- NEXT\n\nThese macros are useful for creating visualizations that relate to data from \"today\", \"yesterday\", \"this month\", \"next year\" etc.\n\n### \"THIS\" Macro\n\nTHIS macro references the current value of the specified date granularity.\n\nIn the following example, THIS macro is used with the day granularity, effectively meaning *this day*, or \"today\":\n\n```\nSELECT {metric/payment} WHERE {attribute/date} = THIS(DAY)\n```\n\nIf the date granularity of the macro changes, so does the meaning of THIS. You can use following time macro granularities:\n\n- DAY\n- MONTH\n- QUARTER\n- YEAR\n- WEEK\n- WEEKOFYEAR\n- MONTHOFYEAR\n- QUARTEROFYEAR\n- DAYOFMONTH\n- DAYOFWEEK\n- DAYOFYEAR\n\nOther date granularities supported by GoodData platform (such as HOUR, MINUTE etc.) are currently not available for time macros.\n\n### Referencing past or future dates\n\nOptionally you can specify second parameter of THIS macro to reference future\nor previous time periods. For example,\n\n```\nSELECT {metric/payment} WHERE {attribute/month} = THIS(Month, -2)\n```\n\ncomputes payments of the month two months ago.\n\nTo illustrate more, suppose the current date is **November 3, 2014**.\nThen following table summarizes values of THIS macro for various combinations of granularities (in rows) and period shifts (columns).\nNote that `THIS(<granularity>, 0)` is equivalent to `THIS(<granularity>)`.\n\n|  | 0 | 2 | -1 |\n| - | - | - | - |\n| Day | 11/3/2014 | 11/5/2014 |  11/2/2014 |\n| DayOfWeek | 1 (Monday) | 3 (Wednesday) | 0 (Sunday) |\n| MonthOfYear | 11 (November) | 1 (January) | 10 (October) |\n| QuarterOfYear | Q4 | Q2 | Q3 |\n| Quarter | Q4/2014 | Q2/2015 | Q3/2014 |\n\n\nNotice that if the date granularity is periodic, such as QuarterOfYear (Q1, Q2,\nQ3, Q4) or MonthOfYear (January, February, March, etc), the resulting value might roll over to the next or\nbackward to the previous period.\n\n### \"PREVIOUS\" and \"NEXT\" Macros\n\nFor convenience MAQL also supports shortcuts for the other two most common relative periods: previous and next.\n\n- `PREVIOUS(<granularity>)` is equivalent to `THIS(<granularity>, -1)`\n- `NEXT(<granularity>)` is equivalent to `THIS(<granularity>, 1)`\n- `PREVIOUS(<granularity>, <shift>)` is equivalent to `THIS(<granularity>, - <shift>)`\n- `NEXT(<granularity>, <shift>)` is equivalent to `THIS(<granularity>, shift>)`\n\nExample:\n\n```\nSELECT {metric/payment} WHERE {attribute/month} = PREVIOUS(Month)\n```";
+        readonly "for-each": "# FOR EACH\nThe **FOR EACH** clause allows you to display all attribute values in your visualization, even if they are missing.\n\nIf you want to display how many visits are planned for each particular month, the visualization normally shows you all months with at least one visit planned.\n\n![Table](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins02.png)\n\nIf you use the **FOR EACH** for month of the year, the visualization will show you also the months that have no visits planned. \n\n![FOR Each in Metric](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins01.png)\n\nWhen creating metrics with `FOR EACH`, remember that:\n\n* The visualizations in Analytical Designer must be sliced with the same attributes that are used in the `FOR EACH` clauses to display the missing values. Otherwise, `FOR EACH` is ignored.\n\n* If the visualization contains multiple metrics with `FOR EACH` applied, the visualization displays all attribute values. \n\n* When `FOR EACH` is applied, the visualization displays all attribute values between the first and the last metric values available. \n    \n    ![Metrics in Separate Visualizations](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins04.png)\n\n    If the visualization contains multiple metrics, it displays attribute values from all metrics.\n\n     ![Metrics in One Visualizations](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins05.png)\n\nYou can also select the **show all values** option in your visualizations in Analytical Designer to display similar results. For details, see [FOR EACH versus Show All Values](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/for-each/#for-each-versus-show-all-values) and [Create Visualizations](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-visualizations/).\n\n#### Day versus Day of Week\n\nWhen With date attributes, the `FOR EACH` clause displays the following:\n\n* For `month` and similar, the `FOR EACH` clause displays attribute values from the first to the last metric values available, including the missing values in between.\n    ![Month](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins06.png)\n\n* For `month of year` and similar date attributes, the `FOR EACH` clause display always all attribute values.\n     ![Month of Year](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins07.png)\n\n\n\n#### FOR EACH versus Show All Values\n\nThe `FOR EACH` clause and the `Show all values` option in Analytical Designer show similar results.\n\n* `FOR EACH` displays attribute values between the first and the last metric values of each metric, including the missing values in between. \n\n    If any attribute value falls outside of such intervals for all metrics, it is not displayed.\n\n    ![Metrics in Separate Visualizations](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins08.png)\n\n* `Show all values` displays all attribute values regardless of the metric values available.\n\n    ![Metrics in Separate Visualizations](https://www.gooddata.com/developers/cloud-native/doc/maql/outerjoins09.png)\n\n\n\n## Syntax\n\n```\nSELECT ... BY ... FOR EACH (attribute/label), (attribute/label), ...\n```\n\n## Examples\n\nDisplay the sum for all sold items every month. The `FOR EACH` clause displays also items and months with no sale.\n```\nSELECT SUM(fact/sales) FOR EACH (attribute/saledate.month), (attribute/item)\n```\n\nDisplay the moving average. The `FOR EACH` clause displays also the days without any change.\n```\nSELECT RUNAVG({metric/value}) ROWS BETWEEN 6 PRECEDING AND CURRENT ROW FOR EACH(date.day)\n```\n\nDisplay the moving average. The `FOR EACH` clause displays also the days without any change and shows missing values as zeros. \n```\nSELECT RUNAVG( IFNULL({metric/value},0)) ROWS BETWEEN 6 PRECEDING AND CURRENT ROW FOR EACH(date.day)\n```\n\nDisplay the bottom 10 products with the lowest number of orders. The `FOR EACH` clause counts also the products with no orders.\n```\nSELECT COUNT({label/order_id}) FOR EACH {label/product_name} WHERE BOTTOM(10) OF (COUNT({label/order_id}) )\n```\n\n## Data Source Support for Dates\n\nSome of the data sources may not fully support FOR EACH with **date attributes**:\n\n* *Dremio*, *Drill*, *Redshift*, and *Synapse* do not support FOR EACH for date attributes.\n\n* *SQL Server 2022 (16.x)*, *Azure SQL Database* and *Azure SQL Managed Instance* support date attributes only from the compatibility level 160.\n\nOther data sources fully support FOR EACH for all attributes.\n\nYou can create metrics with FOR EACH even if your data source does not support it. If you add such metric to a visualization, Analytical Designer will display an error.\n{{% /alert %}}";
+        readonly "for-next-period": "# FOR NextPeriod\nFOR NextPeriod function allows you to compute a metric for a future time\nperiod the granularity of which is determined contextually by the most\ngranular date attribute that is defined in the visualization.\n\nFOR NextPeriod works similarly to FOR Next function unless the\nadaptable functions adapt to the context of the visualization. Even\nthough the metric is defined as FOR NextPeriod(Quarter), for example,\nthe function returns values from the next month, as month is the most\ngranular date attribute in this visualization.\n\n## Syntax\n\n```\nSELECT … FOR NextPeriod(…,…)\nSELECT metric FOR NextPeriod( time_attribute )\n```\n\n## Examples\n\n```\nSELECT {metric/revenue} FOR NextPeriod({attribute/quarter} )\nSELECT {metric/payment} FOR NextPeriod({attribute/quarter} , 3)\n```\n\nAs was the case for the functions Previous( ) and PreviousPeriod( ), see\n[Functions For Referring to Past Time Periods](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/functions-for-referring-to-past-time-periods/),\nthe differences between Next( ) and NextPeriod( ) become most relevant\nwhen a visualization contains a more granular date attribute than the one that is specified\nwithin the functions themselves.\n\nThe chart below demonstrates the\ndifferences between `Leads FOR Next{attribute/quarter})` and `Leads FOR\nNextPeriod{attribute/quarter})` in a visualization broken across a more granular *Date*\nattribute.\n\n![iThe Next( ) function strictly follows the date attribute specified within the functions parentheses.](https://www.gooddata.com/developers/cloud-native/doc/maql/for-next-period.jpg)";
+        readonly "for-next": "# FOR Next\nBy default, the FOR Next function refers to values from one time period\nin the future. This can be customized by adding a second parameter to\nthe function.\n\n## Syntax\n\n```\nSELECT … FOR Next(…,…)\nSELECT metric FOR Next(time_attribute)\n```\n\n## Examples\n\n```\nSELECT {metric/revenue} FOR Next({attribute/quarter})\n```\n\nYou can customize FOR Next() by adding a second parameter to the\nfunction. For example, you might want to return a payment value from\nthree quarters in the future with respect to a certain time period (see\nbelow).\n\n```\nSELECT {metric/payment} FOR Next({attribute/quarter},3)\n```";
+        readonly "for-previous-period": "# FOR PreviousPeriod\nThe FOR PreviousPeriod function is similar to FOR Previous functions\nunless the adaptable functions adapt to the context of the visualization by\nhand.\n\nEven though the metric is defined as FOR PreviousPeriod({attribute/quarter}),\nfor example, the function returns values from the previous month, as\nmonth is the most granular date attribute in this visualization.\n\n## Syntax\n\n```\nSELECT … FOR PreviousPeriod(…,…)\nSELECT metric FOR PreviousPeriod(time_attribute)\n```\n\n## Examples\n\n```\nSELECT {metric/payment} FOR PreviousPeriod({attribute/quarter})\nSELECT {metric/payment} FOR PreviousPeriod({attribute/quarter}, 2)\n```\n\nFor differences between FOR Previous and FOR PreviousPeriod,\nsee [Functions For Referring to Past Time Periods](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/functions-for-referring-to-past-time-periods/).";
+        readonly "for-previous": "# FOR Previous\nBy default, the FOR Previous function refers to values from one time\nperiod ago. You can customize FOR Previous by adding a second parameter\nto the function.\n\n## Syntax\n\n```\nSELECT … FOR Previous(…,…)\nSELECT metric FOR Previous(time_attribute)\nSELECT metric FOR Previous(time_attribute, #periods_ago)\n```\n\n## Examples\n\n```\nSELECT {metric/revenues} FOR Previous({attribute/quarter})\n```\n\nYou can customize FOR Previous() by adding a second parameter to the function. For\nexample, you may want to return a revenue value from three quarters ago\n(see below).\n\n```\nSELECT {metric/revenues} FOR Previous({attribute/quarter} , 3)\n```\n\nFor differences between FOR Previous and FOR PreviousPeriod,\nsee [Functions For Referring to Past Time Periods](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/functions-for-referring-to-past-time-periods/).";
+        readonly "functions-for-referring-to-past-time-periods": "# Functions For Referring to Past Time Periods\nThe following MAQL functions allow you to create metrics showing a time\nover time comparison (for example, month over month, or quarter over\nquarter) of past time periods:\n\n-   [FOR Previous](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/for-previous/)\n-   [FOR PreviousPeriod](https://www.gooddata.com/developers/cloud-native/doc/hosted/create-metrics/maql/time/for-previous-period/)\n\n## Differences Between FOR Previous and FOR PreviousPeriod\n\nThe difference between the Previous( ) and PreviousPeriod( ) functions\nbecomes clear when the date attribute in a visualization is more granular than the\ndate attribute specified within the function's parentheses.\n\nFOR Previous( ) strictly follows the date attribute specified by the\nmetric author within the parentheses of the function.\n\nOn the other hand, FOR PreviousPeriod( ) adapts to the context of the\nvisualization. Regardless of the date attribute specified by the metric, the PreviousPeriod( ) function takes on the date attribute of the smallest granularity in the visualization.\n\nIn the following example, even though the metric in the final column has\nbeen defined as `FOR PreviousPeriod(quarter)`, the function returns\nvalues from the previous *month*, as month is the most granular date\nattribute in this visualization.\n\nThe Previous( ) function strictly follows the date attribute specified within the function's parentheses. PreviousPeriod ( ) takes on the most granular date attribute that is contained within the visualization.\n\n![PreviousPeriod](https://www.gooddata.com/developers/cloud-native/doc/maql/for-previous-period.png)\n\nEven if PreviousPeriod( ) automatically takes on the granularity of the\nsmallest date attribute in a visualization, it is still important to specify a\ndate attribute within the PreviousPeriod( ) function as a way of\nspecifying the date dimension of interest. This is because workspaces\noften have multiple date dimensions, such as Date(Lead Created),\nDate(MQL Qualified), or Date(Snapshot).";
+    };
+};
+export type ResolveTag = keyof (typeof docsIndex)["en-us"];
+//# sourceMappingURL=index.d.ts.map

package/esm/docs/index.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/docs/index.ts"],"names":[],"mappings":"AAqEA;;;;GAIG;AACH,eAAO,MAAM,OAAO,YAAI,OAAO,CAAU,CAAC;AAE1C;;GAEG;AACH,MAAM,MAAM,MAAM,GAAG,CAAC,OAAO,OAAO,CAAC,CAAC,MAAM,CAAC,CAAC;AAE9C,eAAO,MAAM,SAAS;aAClB,OAAO;iBACH,iBAAiB;iBACjB,GAAG;iBACH,KAAK;iBACL,KAAK;iBACL,IAAI;iBACJ,GAAG;iBACH,MAAM;iBACN,GAAG;iBACH,GAAG;iBACH,IAAI;iBACJ,cAAc;iBACd,MAAM;iBACN,gCAAgC;iBAChC,kCAAkC;iBAClC,gCAAgC;iBAChC,iCAAiC;iBACjC,qDAAqD;iBAErD,gCAAgC;iBAChC,QAAQ;iBACR,0CAA0C;iBAC1C,EAAE;iBACF,oBAAoB;iBACpB,oBAAoB;iBACpB,uBAAuB;iBACvB,uBAAuB;iBACvB,GAAG;iBACH,GAAG;iBACH,EAAE;iBACF,8BAA8B;iBAC9B,GAAG;iBACH,uBAAuB;iBACvB,OAAO;iBACP,GAAG;iBACH,KAAK;iBACL,QAAQ;iBACR,KAAK;iBACL,EAAE;iBACF,GAAG;iBACH,KAAK;iBACL,KAAK;iBACL,IAAI;iBACJ,IAAI;iBACJ,KAAK;iBACL,UAAU;iBACV,iBAAiB;iBACjB,wBAAwB;iBACxB,wBAAwB;iBACxB,eAAe;iBACf,sBAAsB;iBACtB,gBAAgB;iBAChB,qCAAqC;iBACrC,mCAAmC;iBACnC,MAAM;iBACN,sBAAsB;iBACtB,yBAAyB;iBACzB,8BAA8B;iBAC9B,oBAAoB;iBACpB,cAAc;iBACd,eAAe;iBACf,aAAa;iBACb,UAAU;iBACV,iBAAiB;iBACjB,UAAU;iBACV,qBAAqB;iBACrB,cAAc;iBACd,8CAA8C;;CAE5C,CAAC;AAEX,MAAM,MAAM,UAAU,GAAG,MAAM,CAAC,OAAO,SAAS,CAAC,CAAC,OAAO,CAAC,CAAC"}

package/esm/docs/index.js

@@ -0,0 +1,143 @@
+// (C) 2021-2026 GoodData Corporation
+import { content as cont__approximate_count } from "./en/docs/create-metrics/maql/aggregation/approximate_count.js";
+import { content as cont__avg } from "./en/docs/create-metrics/maql/aggregation/avg.js";
+import { content as cont__count } from "./en/docs/create-metrics/maql/aggregation/count.js";
+import { content as cont__first } from "./en/docs/create-metrics/maql/aggregation/first.js";
+import { content as cont__last } from "./en/docs/create-metrics/maql/aggregation/last.js";
+import { content as cont__max } from "./en/docs/create-metrics/maql/aggregation/max.js";
+import { content as cont__median } from "./en/docs/create-metrics/maql/aggregation/median.js";
+import { content as cont__min } from "./en/docs/create-metrics/maql/aggregation/min.js";
+import { content as cont__sum } from "./en/docs/create-metrics/maql/aggregation/sum.js";
+import { content as cont__case } from "./en/docs/create-metrics/maql/conditionals/case.js";
+import { content as cont__if_then_else } from "./en/docs/create-metrics/maql/conditionals/if-then-else.js";
+import { content as cont__ifnull } from "./en/docs/create-metrics/maql/conditionals/ifnull.js";
+import { content as cont__filtering_with_ranking_filters } from "./en/docs/create-metrics/maql/filters/filtering-with-ranking-filters.js";
+import { content as cont__filtering_with_the_having_clause } from "./en/docs/create-metrics/maql/filters/filtering-with-the-having-clause.js";
+import { content as cont__filtering_with_the_like_clause } from "./en/docs/create-metrics/maql/filters/filtering-with-the-like-clause.js";
+import { content as cont__filtering_with_the_where_clause } from "./en/docs/create-metrics/maql/filters/filtering-with-the-where-clause.js";
+import { content as cont__by_all_in_all_other_dimensions_except_for_attribute } from "./en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions-except-for-attribute.js";
+import { content as cont__by_all_in_all_other_dimensions } from "./en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all-in-all-other-dimensions.js";
+import { content as cont__by_all } from "./en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-all.js";
+import { content as cont__by_attribute_all_in_all_other_dimensions } from "./en/docs/create-metrics/maql/filters/overriding-attribute-filters/by-attribute-all-in-all-other-dimensions.js";
+import { content as cont__by } from "./en/docs/create-metrics/maql/filters/overriding-attribute-filters/by.js";
+import { content as cont__with_parent_except } from "./en/docs/create-metrics/maql/filters/overriding-parent/with-parent-except.js";
+import { content as cont__with_parent_filter } from "./en/docs/create-metrics/maql/filters/overriding-parent/with-parent-filter.js";
+import { content as cont__without_parent_except } from "./en/docs/create-metrics/maql/filters/overriding-parent/without-parent-except.js";
+import { content as cont__without_parent_filter } from "./en/docs/create-metrics/maql/filters/overriding-parent/without-parent-filter.js";
+import { content as cont__and } from "./en/docs/create-metrics/maql/logical-operators/and.js";
+import { content as cont__not } from "./en/docs/create-metrics/maql/logical-operators/not.js";
+import { content as cont__or } from "./en/docs/create-metrics/maql/logical-operators/or.js";
+import { content as cont__maql_and_multidimensionality } from "./en/docs/create-metrics/maql/maql-and-multidimensionality.js";
+import { content as cont__abs } from "./en/docs/create-metrics/maql/math/abs.js";
+import { content as cont__arithmetic_operations } from "./en/docs/create-metrics/maql/math/arithmetic-operations.js";
+import { content as cont__ceiling } from "./en/docs/create-metrics/maql/math/ceiling.js";
+import { content as cont__exp } from "./en/docs/create-metrics/maql/math/exp.js";
+import { content as cont__floor } from "./en/docs/create-metrics/maql/math/floor.js";
+import { content as cont__greatest } from "./en/docs/create-metrics/maql/math/greatest.js";
+import { content as cont__least } from "./en/docs/create-metrics/maql/math/least.js";
+import { content as cont__ln } from "./en/docs/create-metrics/maql/math/ln.js";
+import { content as cont__log } from "./en/docs/create-metrics/maql/math/log.js";
+import { content as cont__power } from "./en/docs/create-metrics/maql/math/power.js";
+import { content as cont__round } from "./en/docs/create-metrics/maql/math/round.js";
+import { content as cont__sign } from "./en/docs/create-metrics/maql/math/sign.js";
+import { content as cont__sqrt } from "./en/docs/create-metrics/maql/math/sqrt.js";
+import { content as cont__trunc } from "./en/docs/create-metrics/maql/math/trunc.js";
+import { content as cont__percentile } from "./en/docs/create-metrics/maql/ranking/percentile.js";
+import { content as cont__rank_variations } from "./en/docs/create-metrics/maql/ranking/rank-variations.js";
+import { content as cont__where_top_or_bottom_in } from "./en/docs/create-metrics/maql/ranking/where-top-or-bottom-in.js";
+import { content as cont__where_top_or_bottom_of } from "./en/docs/create-metrics/maql/ranking/where-top-or-bottom-of.js";
+import { content as cont__within_clause } from "./en/docs/create-metrics/maql/ranking/within-clause.js";
+import { content as cont__relational_operators } from "./en/docs/create-metrics/maql/relational-operators.js";
+import { content as cont__rolling_window } from "./en/docs/create-metrics/maql/runing-totals/rolling-window.js";
+import { content as cont__running_total_statistical_functions } from "./en/docs/create-metrics/maql/runing-totals/running-total-statistical-functions.js";
+import { content as cont__running_totals_for_core_functions } from "./en/docs/create-metrics/maql/runing-totals/running-totals-for-core-functions.js";
+import { content as cont__correl } from "./en/docs/create-metrics/maql/statistic/correl.js";
+import { content as cont__covariance_functions } from "./en/docs/create-metrics/maql/statistic/covariance-functions.js";
+import { content as cont__least_squares_functions } from "./en/docs/create-metrics/maql/statistic/least-squares-functions.js";
+import { content as cont__standard_deviation_functions } from "./en/docs/create-metrics/maql/statistic/standard-deviation-functions.js";
+import { content as cont__variance_functions } from "./en/docs/create-metrics/maql/statistic/variance-functions.js";
+import { content as cont__datetime_add } from "./en/docs/create-metrics/maql/time-arithmetics/datetime-add.js";
+import { content as cont__datetime_diff } from "./en/docs/create-metrics/maql/time-arithmetics/datetime-diff.js";
+import { content as cont__time_macros } from "./en/docs/create-metrics/maql/time-macros.js";
+import { content as cont__for_each } from "./en/docs/create-metrics/maql/time/for-each.js";
+import { content as cont__for_next_period } from "./en/docs/create-metrics/maql/time/for-next-period.js";
+import { content as cont__for_next } from "./en/docs/create-metrics/maql/time/for-next.js";
+import { content as cont__for_previous_period } from "./en/docs/create-metrics/maql/time/for-previous-period.js";
+import { content as cont__for_previous } from "./en/docs/create-metrics/maql/time/for-previous.js";
+import { content as cont__functions_for_referring_to_past_time_periods } from "./en/docs/create-metrics/maql/time/functions-for-referring-to-past-time-periods.js";
+/**
+ * IETF BCP 47 language tags for supported locales in documentation
+ *
+ * @internal
+ */
+export const locales = ["en-us"];
+export const docsIndex = {
+    "en-us": {
+        approximate_count: cont__approximate_count,
+        avg: cont__avg,
+        count: cont__count,
+        first: cont__first,
+        last: cont__last,
+        max: cont__max,
+        median: cont__median,
+        min: cont__min,
+        sum: cont__sum,
+        case: cont__case,
+        "if-then-else": cont__if_then_else,
+        ifnull: cont__ifnull,
+        "filtering-with-ranking-filters": cont__filtering_with_ranking_filters,
+        "filtering-with-the-having-clause": cont__filtering_with_the_having_clause,
+        "filtering-with-the-like-clause": cont__filtering_with_the_like_clause,
+        "filtering-with-the-where-clause": cont__filtering_with_the_where_clause,
+        "by-all-in-all-other-dimensions-except-for-attribute": cont__by_all_in_all_other_dimensions_except_for_attribute,
+        "by-all-in-all-other-dimensions": cont__by_all_in_all_other_dimensions,
+        "by-all": cont__by_all,
+        "by-attribute-all-in-all-other-dimensions": cont__by_attribute_all_in_all_other_dimensions,
+        by: cont__by,
+        "with-parent-except": cont__with_parent_except,
+        "with-parent-filter": cont__with_parent_filter,
+        "without-parent-except": cont__without_parent_except,
+        "without-parent-filter": cont__without_parent_filter,
+        and: cont__and,
+        not: cont__not,
+        or: cont__or,
+        "maql-and-multidimensionality": cont__maql_and_multidimensionality,
+        abs: cont__abs,
+        "arithmetic-operations": cont__arithmetic_operations,
+        ceiling: cont__ceiling,
+        exp: cont__exp,
+        floor: cont__floor,
+        greatest: cont__greatest,
+        least: cont__least,
+        ln: cont__ln,
+        log: cont__log,
+        power: cont__power,
+        round: cont__round,
+        sign: cont__sign,
+        sqrt: cont__sqrt,
+        trunc: cont__trunc,
+        percentile: cont__percentile,
+        "rank-variations": cont__rank_variations,
+        "where-top-or-bottom-in": cont__where_top_or_bottom_in,
+        "where-top-or-bottom-of": cont__where_top_or_bottom_of,
+        "within-clause": cont__within_clause,
+        "relational-operators": cont__relational_operators,
+        "rolling-window": cont__rolling_window,
+        "running-total-statistical-functions": cont__running_total_statistical_functions,
+        "running-totals-for-core-functions": cont__running_totals_for_core_functions,
+        correl: cont__correl,
+        "covariance-functions": cont__covariance_functions,
+        "least-squares-functions": cont__least_squares_functions,
+        "standard-deviation-functions": cont__standard_deviation_functions,
+        "variance-functions": cont__variance_functions,
+        "datetime-add": cont__datetime_add,
+        "datetime-diff": cont__datetime_diff,
+        "time-macros": cont__time_macros,
+        "for-each": cont__for_each,
+        "for-next-period": cont__for_next_period,
+        "for-next": cont__for_next,
+        "for-previous-period": cont__for_previous_period,
+        "for-previous": cont__for_previous,
+        "functions-for-referring-to-past-time-periods": cont__functions_for_referring_to_past_time_periods,
+    },
+};

package/esm/findObjects.d.ts

@@ -0,0 +1,13 @@
+import { MaqlMetric } from "./parseMaql.js";
+import { type IMaqlObject } from "./tokenRanges.js";
+/**
+ * A `{type/id}` reference together with where it sits in the metric's own text.
+ */
+export interface IMaqlObjectAt extends IMaqlObject {
+    readonly offsets: {
+        readonly start: number;
+        readonly end: number;
+    };
+}
+export declare function findAllObjects(metric: MaqlMetric): IMaqlObjectAt[];
+//# sourceMappingURL=findObjects.d.ts.map

package/esm/findObjects.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"findObjects.d.ts","sourceRoot":"","sources":["../src/findObjects.ts"],"names":[],"mappings":"AAoBA,OAAO,EAAE,UAAU,EAAE,MAAM,gBAAgB,CAAC;AAC5C,OAAO,EAAE,KAAK,WAAW,EAAqB,MAAM,kBAAkB,CAAC;AAEvE;;GAEG;AACH,MAAM,WAAW,aAAc,SAAQ,WAAW;IAC9C,QAAQ,CAAC,OAAO,EAAE;QAAE,QAAQ,CAAC,KAAK,EAAE,MAAM,CAAC;QAAC,QAAQ,CAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAC;CACtE;AAED,wBAAgB,cAAc,CAAC,MAAM,EAAE,UAAU,GAAG,aAAa,EAAE,CAIlE"}