Import metric reference entries in Holistics datasets#228
Conversation
The reusable-metric-store shorthand `metric name: standalone_metric` references a top-level Metric by name instead of redefining it inline. The parser represents that reference as a property rather than a block, so the dataset-block loop dropped it. A Dataset that extends a PartialDataset whose only contribution is such a reference then produced no model at all. Resolve metric-reference property entries against the standalone Metric registry (renamed to the dataset-local key) so the dataset still surfaces with the referenced metric attached.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f53b3671a4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| # Try the name as written, then qualified against the referencing file's | ||
| # module prefix / `use` aliases, matching how standalone metrics are keyed. | ||
| candidates = [name, _qualify_name(name, context)] |
There was a problem hiding this comment.
Resolve local metric refs before global fallback
When a Dataset/PartialDataset is authored inside a module and references a bare standalone metric name, this tries the unqualified key before the context-qualified key. If both a root Metric revenue and modules/finance/Metric revenue exist, a finance partial with metric revenue: revenue resolves to the root metric instead of finance.revenue, giving the extending dataset the wrong SQL. Other resolver paths qualify bare names in context first, so this should prefer _qualify_name(name, context) before falling back to name.
Useful? React with 👍 / 👎.
Follow-up to #204.
What & why
The Holistics reusable-metric-store shorthand
metric name: standalone_metricreferences a top-levelMetricby name instead of redefining it inline. The parser represents that reference as a property (not a block), so the dataset-block item loop insidemantic/adapters/holistics.pydropped it viacontinue.As a result, a
Dataset d = base.extend(partial_metrics)whose partial only contributes such metric references produced nodmodel at all, even though the referenced standaloneMetricexisted.PartialDataset.extendonly worked when every reusable metric was rewritten as a full inline block.This change resolves metric-reference property entries against the standalone
Metricregistry (copied and renamed to the dataset-local key) so the dataset still surfaces as a model carrying the referenced metric. Standalone metrics are now resolved before datasets so the reference can be resolved at dataset-parse time. Genuine dataset properties (label,description,models,relationships) are untouched because only values that resolve to a known standalone metric are pulled in.Known limitations
usealiases; a reference that cannot be matched to a known standalone metric is left as before (no spurious metric created).