Skip to content

Commit

Permalink
Merge pull request #470 from dbt-labs/repo-sync
Browse files Browse the repository at this point in the history
REPO SYNC - Public to Private
  • Loading branch information
john-rock authored Mar 11, 2024
2 parents 1161490 + 4253e9c commit 1b1677b
Show file tree
Hide file tree
Showing 2 changed files with 24 additions and 17 deletions.
17 changes: 12 additions & 5 deletions website/docs/docs/build/metricflow-commands.md
Original file line number Diff line number Diff line change
Expand Up @@ -156,8 +156,10 @@ Options:
[required]
--end-time TEXT Optional iso8601 timestamp to constraint the end time of
the data (inclusive)
*Not available in dbt Cloud yet
--start-time TEXT Optional iso8601 timestamp to constraint the start time
of the data (inclusive)
*Not available in dbt Cloud yet
--help Show this message and exit.
```

Expand Down Expand Up @@ -268,10 +270,12 @@ Options:
ds, org.

--end-time TEXT Optional iso8601 timestamp to constraint the end
time of the data (inclusive)
time of the data (inclusive).
*Not available in dbt Cloud yet

--start-time TEXT Optional iso8601 timestamp to constraint the start
time of the data (inclusive)
*Not available in dbt Cloud yet

--where TEXT SQL-like where statement provided as a string. For
example: --where "revenue > 100". To add a dimension filter to
Expand Down Expand Up @@ -306,7 +310,7 @@ Options:
### Query examples
The following tabs present various different types of query examples that you can use to query metrics and dimensions. Select the tab that best suits your needs:
The following tabs present various types of query examples that you can use to query metrics and dimensions. Select the tab that best suits your needs:
<Tabs>
Expand Down Expand Up @@ -428,11 +432,14 @@ mf query --metrics order_total --group-by metric_time --where "{{ Dimension('ord
To filter by time, there are dedicated start and end time options. Using these options to filter by time allows MetricFlow to further optimize query performance by pushing down the where filter when appropriate.
**Query**
```bash
<!--
bash not support in cloud yet
# In dbt Cloud
dbt sl query --metrics order_total --group-by metric_time,is_food_order --limit 10 --order -metric_time --where "is_food_order = True" --start-time '2017-08-22' --end-time '2017-08-27'
-->
**Query**
```bash
# In dbt Core
mf query --metrics order_total --group-by metric_time,is_food_order --limit 10 --order -metric_time --where "is_food_order = True" --start-time '2017-08-22' --end-time '2017-08-27'
```
Expand Down
24 changes: 12 additions & 12 deletions website/docs/reference/dbt-jinja-functions/builtins.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,23 +22,27 @@ Using the `builtins` variable in this way is an advanced development workflow. U
:::

<VersionBlock firstVersion="1.5">

From dbt v1.5 and higher, use the following macro to extract user-provided arguments, including <code>version</code>, and call the <code>builtins.ref()</code> function with either a single <code>modelname</code> argument or both <code>packagename</code> and <code>modelname</code> arguments, based on the number of positional arguments in <code>varargs</code>:

From dbt v1.5 and higher, use the following macro to override the `ref` method available in the model compilation context to return a [Relation](/reference/dbt-classes#relation) with the database name overriden to `dev`.

It includes logic to extract user-provided arguments, including <code>version</code>, and call the <code>builtins.ref()</code> function with either a single <code>modelname</code> argument or both <code>packagename</code> and <code>modelname</code> arguments, based on the number of positional arguments in <code>varargs</code>.

<br /><br />


```
{% macro ref() %}
-- extract user-provided positional and keyword arguments
{% set version = kwargs.get('version') or kwargs.get('v') %}
{% set packagename = none %}
{%- if (varargs | length) == 1 -%}
{% set version = kwargs.get('version') or kwargs.get('v') %}
{% set packagename = none %}
{%- if (varargs | length) == 1 -%}
{% set modelname = varargs[0] %}
{%- else -%}
{% set packagename = varargs[0] %}
{% set modelname = varargs[1] %}
{% endif %}
-- call builtins.ref based on provided positional arguments
{% set rel = None %}
{% if packagename is not none %}
Expand Down Expand Up @@ -71,14 +75,10 @@ From dbt v1.4 and lower, use the following macro to override the `ref` method av
```
</VersionBlock>

The ref macro can also be used to control which elements of the model path are rendered when run, for example the following macro overrides the `ref` method to render only the schema and object identifier, but not the database reference i.e. `my_schema.my_model` rather than `my_database.my_schema.my_model`. This is especially useful when using snowflake as a warehouse, if you intend to change the name of the database post-build and wish the references to remain accurate.
Logic within the ref macro can also be used to control which elements of the model path are rendered when run, for example the following logic renders only the schema and object identifier, but not the database reference i.e. `my_schema.my_model` rather than `my_database.my_schema.my_model`. This is especially useful when using snowflake as a warehouse, if you intend to change the name of the database post-build and wish the references to remain accurate.

```
-- Macro to override ref and to render identifiers without a database.
{% macro ref(model_name) %}
{% do return(builtins.ref(model_name).include(database=false)) %}
{% endmacro %}
-- render identifiers without a database
{% do return(rel.include(database=false)) %}
```

0 comments on commit 1b1677b

Please sign in to comment.