Skip to content

Commit

Permalink
address doc review comments
Browse files Browse the repository at this point in the history
  • Loading branch information
villebro committed Sep 5, 2024
1 parent d01e3fd commit 0212fa9
Show file tree
Hide file tree
Showing 2 changed files with 6 additions and 7 deletions.
10 changes: 5 additions & 5 deletions docs/docs/configuration/sql-templating.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -17,8 +17,8 @@ made available in the Jinja context:

- `columns`: columns which to group by in the query
- `filter`: filters applied in the query
- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined) (deprecated, use `get_time_filter` instead)
- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). (deprecated, use `get_time_filter` instead)
- `from_dttm`: start `datetime` value from the selected time range (`None` if undefined) (deprecated beginning in version 5.0, use `get_time_filter` instead)
- `to_dttm`: end `datetime` value from the selected time range (`None` if undefined). (deprecated beginning in version 5.0, use `get_time_filter` instead)
- `groupby`: columns which to group by in the query (deprecated)
- `metrics`: aggregate expressions in the query
- `row_limit`: row limit of the query
Expand Down Expand Up @@ -350,7 +350,7 @@ Here's a concrete example:
The `{{ get_time_filter() }}` macro returns the time filter applied to a specific column. This is useful if you want
to handle time filters inside the virtual dataset, as by default the time filter is placed on the outer query. This can
have considerable performance implications, as many databases and query engines are able to optimize the query better
considerably improve performance, as many databases and query engines are able to optimize the query better
if the temporal filter is placed on the inner query, as opposed to the outer query.
The macro takes the following parameters:
Expand All @@ -366,7 +366,7 @@ The macro takes the following parameters:
The return type has the following properties:
- `from_expr`: the start of the time filter (if any)
- `to_expr`: the end of the time filter (if any)
- `time_range`: The time range as defined on the
- `time_range`: The applied time range
Here's a concrete example using the `logs` table from the Superset metastore:
Expand All @@ -387,7 +387,7 @@ FROM logs
Assuming we are creating a table chart with a simple `COUNT(*)` as the metric with a time filter `Last week` on the
`dttm` column, this would render the following query on Postgres (note the formatting of the temporal filters, and
the missing filters on the outer query):
the absence of time filters on the outer query):
```
SELECT COUNT(*) AS count
Expand Down
3 changes: 1 addition & 2 deletions superset/jinja_context.py
Original file line number Diff line number Diff line change
Expand Up @@ -394,8 +394,7 @@ def get_time_filter(
database (e.g. `TIMESTAMP`, `DATE` or `DATETIME`). If `column` is defined,
the format will default to the type of the column. This is used to produce
the format of the `from_expr` and `to_expr` properties of the returned
`TimeFilter` object. Note, that omitting `column` and `target_type` will
render format the temporal values as ISO format.
`TimeFilter` object.
:param remove_filter: When set to true, mark the filter as processed,
removing it from the outer query. Useful when a filter should
only apply to the inner query.
Expand Down

0 comments on commit 0212fa9

Please sign in to comment.