Problem
The MetricFlow → Ossie converter can silently lose time-context semantics from derived metrics.
For example, a month-over-month metric can use an offset input:
- name: month_over_month_growth
type: derived
type_params:
expr: (cur - pre) / pre
metrics:
- name: revenue
alias: cur
- name: revenue
alias: pre
offset_window:
count: 1
granularity: monthThe current converter flattens this into an ordinary Ossie SQL expression:
(SUM(orders.amount) - SUM(orders.amount)) / SUM(orders.amount)
The pre offset semantics are lost. A top-level cumulative metric emits CUMULATIVE_SEMANTICS_LOSS, but a derived metric using offset-period inputs does not emit an equivalent warning.
Expected behavior
The converter should report a ConverterIssue for derived metrics using non-portable time-context semantics, including offset_window, offset_to_grain, rolling windows, and grain-to-date semantics. The warning should identify the metric whose semantics were lost.
Strict mode could fail conversion instead of emitting a potentially misleading ordinary SQL expression.
Problem
The MetricFlow → Ossie converter can silently lose time-context semantics from derived metrics.
For example, a month-over-month metric can use an offset input:
The current converter flattens this into an ordinary Ossie SQL expression:
The
preoffset semantics are lost. A top-level cumulative metric emitsCUMULATIVE_SEMANTICS_LOSS, but a derived metric using offset-period inputs does not emit an equivalent warning.Expected behavior
The converter should report a
ConverterIssuefor derived metrics using non-portable time-context semantics, includingoffset_window,offset_to_grain, rolling windows, and grain-to-date semantics. The warning should identify the metric whose semantics were lost.Strict mode could fail conversion instead of emitting a potentially misleading ordinary SQL expression.