Repository navigation
Downstream dialect allowlists don't recognize OSSIE_SQL_2026 #442
Description
Background
#439 added OSSIE_SQL_2026 as a dialect in the core spec, and #440 added the matching value to the Python OssieDialect enum. Documents using OSSIE_SQL_2026 now pass model validation, but several downstream components hard-code dialect allowlists that predate this dialect and don't recognize it. As a result, fields/metrics expressed only in OSSIE_SQL_2026 are silently dropped or produce misleading warnings, even though the dialect is ANSI-SQL-compatible.
Affected locations
converters/orionbelt/src/ossie_orionbelt/_common.py:41—_SQL_PARSEABLE_DIALECTStuple omitsOSSIE_SQL_2026, so_select_sql_expression()drops such metrics from OBML export with a "no SQL-parseable dialect" warning.converters/snowflake/src/ossie_snowflake/converter.py:372—_extract_expression()only recognizesSNOWFLAKE/ANSI_SQL, so matching fields/metrics are skipped from Snowflake export with a misleading warning.converters/databricks/src/ossie_databricks/_common.py:231—pick_expression()only falls back throughDATABRICKS/ANSI_SQL, returningNoneand causing the field/metric to be dropped from Databricks Metric View output.converters/wisdom/src/ossie_wisdom/ossie_to_wisdom.py:148—_infer_dataset_dialect()/_pick_expression()never checkOSSIE_SQL_2026, producing a spuriousMISSING_DIALECT_EXPRESSIONissue even though a fallback expression is still used.validation/validate.py:67—DIALECT_MAP/SKIP_SQL_VALIDATIONomitOSSIE_SQL_2026; it currently validates correctly only by accident, becausedict.get()'s default happens to match the sameNonesentinel used forANSI_SQL. This should be made an explicit mapping rather than relying on that coincidence.
Suggested fix
Treat OSSIE_SQL_2026 as ANSI-SQL-compatible in each of the allowlists/fallback chains above (mirroring how ANSI_SQL is handled), and add regression tests per converter covering a field/metric expressed only in OSSIE_SQL_2026.
Related
Follow-up from review of #440.
Activity
fix(osi): read OSSIE_SQL_2026 expressions and newer non-SQL dialects (#…
fix(databricks): read OSSIE_SQL_2026 metric expressions
fix(databricks): read OSSIE_SQL_2026 metric expressions
fix(databricks): read OSSIE_SQL_2026 metric expressions (#446)
fix(orionbelt): read OSSIE_SQL_2026 metric expressions (#443)
fix(snowflake): read OSSIE_SQL_2026 metric expressions (#447)
fix(wisdom): read OSSIE_SQL_2026 metric expressions (#449)
ihadoop commentedon Oct 10, 2026
Walking through each location this issue names, against current
main(642cb89) — all five now recognise the dialect, so this looks ready for triage:converters/orionbelt/src/ossie_orionbelt/_common.py—_SQL_PARSEABLE_DIALECTS = (ANSI_SQL, OSSIE_SQL_2026, SNOWFLAKE, DATABRICKS), with a comment above it naming this dialect specifically.converters/snowflake/src/ossie_snowflake/converter.py—_extract_expression()documents the preference orderSNOWFLAKE, thenANSI_SQL, thenOSSIE_SQL_2026, and the not-found warning text now saysrequires SNOWFLAKE, ANSI_SQL, or OSSIE_SQL_2026.converters/wisdom/src/ossie_wisdom/ossie_to_wisdom.py— checksOssieDialect.OSSIE_SQL_2026as an ANSI-equivalent fallback, so the spuriousMISSING_DIALECT_EXPRESSIONissue is gone.validation/validate.py—DIALECT_MAPnow carriesOSSIE_SQL_2026: Nonewith the reason stated (ANSI-SQL-compatible, parse with the sqlglot default), so it holds by design rather than by thedict.get()accident this issue described.converters/databricks/...— the Python converter this issue pointed at was removed (chore(databricks): remove the Python converter #531). The Databricks spoke is now Java, and that module has explicit coverage for this issue:OssieConverterSuite.javatests a dimension and a measure expressed only inOSSIE_SQL_2026must export rather than be dropped, citing Downstream dialect allowlists don't recognize OSSIE_SQL_2026 #442 in the comments, plus a case assertingDATABRICKSwins overOSSIE_SQL_2026when both are present.Two caveats so this is not read as broader than it is: I audited the call sites the issue lists, not every dialect comparison in the repo, and I did not run the Java suite locally (no JDK/Gradle here) — the Java evidence above is from reading its test source.
Not my call to close; reporting that the named sites are covered.