fix(orionbelt): export metric expressions that compute what OrionBelt computes

[ralfbecher]

Summary

Other Ossie consumers (the Databricks, Snowflake and dbt converters, BI tools) read a metric's SQL expression, not the ORIONBELT extension. The OrionBelt converter exported SQL that did not compute what OrionBelt computes:

Before	After
SUM(fact_orders.amount): physical table, not the dataset	SUM("Orders"."amount"): <dataset>.<field>, always double-quoted
Measure filters dropped from the SQL	SUM(CASE WHEN <condition> THEN <arg> END)
total: true dropped	Grand-total window SUM(SUM(x)) OVER () (exact SUM/COUNT ratio for AVG)
{[Order Count]} and metric-on-metric refs left unresolved	Synthesized counts and referenced metrics inlined
Period-over-period exported as x / NULLIF(prev.value, 0) - 1 (prev undefined)	Left out with a warning, kept whole in the model extension
Cumulative/window ORDER BY the raw date	Ordered and partitioned by the dimension at its timeGrain, as the query groups it

A measure or metric with no faithful single expression (period-over-period, grain, filterContext, anchor, window over a window, metric reference cycles) is left out of metrics with a warning and kept in the model-level extension (obml_unexported).

The rendering lives in a new _portable.py. It mirrors the OrionBelt compiler and adds no dependencies.

Round trip: every exported measure/metric carries its OBML definition (obml_definition), and every field its OBML column name (obml_column_name). OBML to Ossie to OBML now restores the original model instead of re-parsing filters and totals out of the SQL, where they would be applied twice. Column keys come back under their OBML names, not the physical codes, so several existing test assertions changed accordingly.

aggregation: measure exports MEASURE("<name>") tagged DATABRICKS instead of ANSI_SQL.

These fixes shipped in OrionBelt's in-repo copy of this converter first (ralforion/orionbelt-semantic-layer#480). They were reviewed there and verified against DuckDB.

Note: #410 (datatype in both directions) also edits obml_to_ossie.py and ossie_to_obml.py. Whichever lands second needs a small rebase. I'll do it.

Related Issues

None filed. Found while testing the OrionBelt to Ossie to Databricks Metric View chain.

Checklist

Converters

• Converter logic in converters/ is updated
• Tests under converters/orionbelt/tests/: new test_ossie_portable_expressions.py, which runs every exported metric in DuckDB grouped as OrionBelt groups it (skipped when duckdb/sqlglot are not installed)

Documentation

• converters/orionbelt/README.md and ossie_obml_mapping_analysis.md updated

Tests

• pytest in converters/orionbelt: 186 passed, 3 skipped (189 passed with duckdb and sqlglot)
• ruff check / mypy report nothing new

Compliance

• ASF license headers on the new source and test files
• No third-party dependencies added

[jbonofre]

LGTM (just a very minor nit about import order in a test).

Thanks @ralfbecher !

[jbonofre]

Nit: running ruff check on the new test file raises an I001 (isort) violation due to the import order of pytest and ossie_orionbelt.

I suggest to run ruff check --fix on test_ossie_portable_expression.py to keep the linter clean.

[ralfbecher]

Thanks! I could reproduce it only with ruff before 0.6 (or --isolated): those versions do not look in src/ for first-party packages, so ossie_orionbelt sorts as third-party. That flags test_ossie_v02_compat.py, test_ossie_metric_no_silent_loss.py, test_ossie_tpcds_baseline.py and test_ossie_converter_cumulative.py the same way, while current ruff (0.15) passes all of them and would flag the reordered file instead.

So rather than reorder this one file, I pinned known-first-party = ["ossie_orionbelt"] under [tool.ruff.lint.isort] in converters/orionbelt/pyproject.toml. ruff check --select I now passes on both ruff 0.5.7 and 0.15.17, with no file changes.