dbt converter ignores OSSIE_SQL_2026 and picks an expression by array position

[RyutoYoda]

Background

core-spec/expression_language.md (status: Proposed Final), under Dialect Extensions, states:

The Ossie dialect should always be supported. Other dialects MAY be ignored. […] if an Ossie model has an expression written in two dialects, the implementation should deterministically choose which dialect to use.

The Ossie → dbt direction does neither. OSSIE_SQL_2026 (#439, #440) is not recognised anywhere in converters/dbt, and where no recognised dialect is found the converter falls back to whichever entry happens to be first in the dialects array. Expression.dialects is minItems: 1 with no ordering or uniqueness constraint, so array position carries no meaning — two semantically identical documents produce different dbt output.

Affected locations

• converters/dbt/src/ossie_dbt/ossie_to_msi.py:407 — _get_expression() matches self._dialect and otherwise returns dialects[0]. self._dialect is always ANSI_SQL: the constructor argument is never passed (cli.py:80, README.md:113, and every test). Shared by the metric path (:273) and the field path (:132).
• converters/dbt/src/ossie_dbt/ossie_to_msi.py:401 — the bare-column dataset scan compares dialects[0] against the column name. If the portable expression is not first the match fails and the metric is attributed to datasets[0] instead.

Reproduction

Two Ossie documents differing only in the order of dialects, through ossie-dbt ossie-to-msi:

dialects	metric expr emitted
[OSSIE_SQL_2026, SNOWFLAKE]	amount
[SNOWFLAKE, OSSIE_SQL_2026]	amt_SNOWFLAKE_ONLY

In the second case a Snowflake-only column reference is written into the MetricFlow output as if it were portable SQL. No warning and no ConverterIssue is produced. The field path behaves the same way for dimension expr.

Suggested fix

Add OSSIE_SQL_2026 to the fallback chain — self._dialect > OSSIE_SQL_2026 > dialects[0] — mirroring #443/#446/#447 for orionbelt/databricks/snowflake. The expression language is based on ANSI SQL:2003 Core, so treating it as an ANSI_SQL equivalent is consistent with those. The change is additive: expressions carrying ANSI_SQL keep their current behaviour.

Note that expression_language.md also proposes making OSSIE_SQL_2026 the default dialect when none is chosen, which would argue for preferring it over ANSI_SQL. That would change existing behaviour, so it is deliberately left out of scope here.

Coverage on main shows lines 403-405 and 412 of ossie_to_msi.py are unreached by the current suite — _ossie_expr() (tests/helpers.py:159) only ever builds single-dialect expressions, so multi-dialect input is untested in this direction. The fix should come with regression tests covering it.

Related

#442 covers the same dialect gap in orionbelt, snowflake, databricks, wisdom and validation, but does not list the dbt converter. #52 and #294 propose spec-level changes to dialect handling; neither removes the need to read OSSIE_SQL_2026 here.