Add OSI ↔ Databricks Unity Catalog Metric View converter

[STHITAPRAJNAS]

Summary

Adds a bidirectional converter between OSI YAML semantic models and
Databricks Unity Catalog Metric View
YAML, under converters/databricks/. Pure offline conversion, Python +
PyYAML, structured like the existing Snowflake converter but with both
directions and round-trip coverage.

DATABRICKS is already in the vendors enum and the dialect enum, so
this PR adds converter code only; no spec change.

Mapping

OSI	Databricks UC Metric View (version: 1.1)
primary fact dataset	source
other reachable datasets	joins[] (source + sql_on)
dataset.fields[]	dimensions[]
metrics[]	measures[]
expression.dialects[DATABRICKS] (else ANSI_SQL)	expr
relationships[].from_columns / to_columns	sql_on boolean
custom_extensions[DATABRICKS] (filter, primary_dataset, raw_joins)	top-level filter, source selection, restored joins

Primary fact dataset is selected in priority order:

1. custom_extensions[vendor_name=DATABRICKS] with {"primary_dataset": "..."}
2. The dataset most often on the from side of relationships
3. The first dataset declared

Datasets unreachable from the primary via the relationship graph emit a
warning and are excluded.

Dimension expression qualification. Bare single-identifier
expressions (e.g. expression: customer_id on customer) are
auto-qualified as customer.customer_id so they resolve unambiguously
after joins. Multi-token expressions (operators, function calls,
multi-column references) are emitted verbatim — string-prepending only
qualifies the first identifier and would silently break the rest. For
computed fields on a non-primary dataset, supply a DATABRICKS dialect
entry that's already table-qualified; the converter prefers it and
silences the warning.

Round-trip behaviour

Round-trip OSI → UC → OSI keeps datasets, relationships, metrics, and
expressions. UC-only fields (filter, the metric view version,
unparseable sql_on clauses) are recorded in
custom_extensions[DATABRICKS] on import and re-emitted on export, so
UC → OSI → UC also survives.

Documented lossy paths:

• OSI dimension.is_time has no dedicated UC counterpart (see Add datatype field to Field and Metric; reframe is_time as role marker #113 —
  the field classifier is isolated so the migration to datatype is a
  one-function change).
• ai_context on relationships is dropped on export with a warning.
• Non-DATABRICKS / non-ANSI_SQL dialect entries are skipped with a
  warning.

Coordination with other open PRs

• Add Apache Spark converter module #93 (Apache Spark converter) — different scope: that PR generates
  generic PySpark code with a DATABRICKS dialect flag, not a Unity
  Catalog metric view. No code overlap; only the DATABRICKS dialect
  string is shared.
• Add datatype field to Field and Metric; reframe is_time as role marker #113 (datatype field, reframe is_time) — when it lands, the
  field classifier becomes a one-function update.

Test plan

• python3 -m pytest converters/databricks/tests/ -q → 47 passed
• python3 -m pyflakes converters/databricks/src/ converters/databricks/tests/ → clean
• python3 -m ruff check converters/databricks/src/ converters/databricks/tests/ → clean
• python3 validation/validate.py examples/tpcds_semantic_model.yaml → passes (TPC-DS is the round-trip fixture)
• TPC-DS converts end-to-end; round-trip preserves dataset names, relationship from_columns/to_columns, and metric expressions

[khush-bhatia]

Hey @STHITAPRAJNAS Thanks for the contribution. We are in process of setting up the CLA hooks to prepare for donation. If you would like to merge this PR before the hooks are setup, could you please join this slack workspace to discuss the steps for the CLA? This is standard process for any ASF project.

[jbonofre]

The PR is solid. I left a couple of comments worth to clarify.

Thanks!

[jbonofre]

I think it conflates join alias with dataset name.

joined_name is derived via _name_from_source(j_source), so the last segment of the table path.

But sql_on clauses can reference the join's name (alias) rather than the source table.
Today the parser requires l_table == primary_name and r_table == joined_name. If an author writes joins: [{name: c, source: main.sales.customers, sql_on: "orders.customer_id = c.id"}], the parser returns None and the relationship is lost (raw clause is preserved, but the OSI graph is incomplete).

You should consider matching against both joined_name and the join's name field.

[jbonofre]

_combined_description only honours string ai_context. The schema's oneOf allows an object with instructions and synonyms. It means a model carrying ai_context: {instructions: "..."} will silently lose that text without warning.

I believe we should either flatten instructions into comment, or warn like the relationship ai_context path does.

[jbonofre]

I'm confused here:

preserved is initially with primary_dataset.

So len(preserved) <= 1 always means "exactly 1", and preserved if preserved else None always returns preserved. So the if is a no-op. Should we remove it?