Replies: 1 comment
|
Reviving this with data from the ThoughtSpot converter mapping (#285). The expression-language doc already assumes filters exist twice. It scopes itself to "metrics, fields, filters, etc" and redirects WHERE to "the filter property". But the core schema defines no such property. In practice every vendor has one (ThoughtSpot has model filters and join constraints; the Databricks Metric View has filter) and every converter is stashing it in custom_extensions today. A stashed filter is invisible to other consumers, which means the same semantic model returns different numbers in two tools — of everything we mapped, this is the highest-value gap in the core spec. Proposal: a minimal core filters construct (column, operator, values) at semantic-model and/or dataset scope, with anything fancier staying vendor-extension. |
Uh oh!
There was an error while loading. Please reload this page.
Just wondering what discussions there have been regarding Model level filters. I.e. the syntax could be
All reactions