Hi all 👋
I'd like to gauge interest in adding a converter between Ossie and Lightdash's semantic definitions under converters/.
Lightdash is an open-source BI platform built on top of dbt. Its semantic layer lives in the dbt project itself: dimensions and metrics are declared per-column in dbt schema.yml files under meta (e.g. meta.dimension: {label, type} and meta.metrics.<name>: {type: sum | count | ... | number, label, sql} with ${TABLE}.column references). Tables are dbt models — conceptually close to Ossie's datasets / fields / metrics, which makes it a natural fit for a hub-and-spoke converter. Lightdash is a member of the Ossie coalition, but there is no converter for it yet.
Worth noting upfront: Lightdash itself just shipped a first cut of native MetricFlow support in the CLI — no dbt Cloud required (lightdash/lightdash#19071, implemented in lightdash/lightdash#25478, released 2026-07-14). lightdash deploy now reads semantic_models / metrics from the dbt manifest and translates the supported subset (simple metrics and create_metric measures) into Lightdash metrics, explicitly citing OSI/MetricFlow as the single source of truth it enables. I see a converter here as complementary to that native direction rather than overlapping with it:
- Import direction (Lightdash → Ossie): teams with an existing installed base of Lightdash
meta metrics need a migration path into Ossie. The native dbt path doesn't cover that.
- Full-fidelity round-trip: MetricFlow's manifest can't carry Lightdash-specific attributes (
format, round, groups, ...) and the native translation currently skips ratio / derived / filtered metrics. A converter can preserve all of that via custom_extensions with a stable vendor_name: lightdash.
- Non-dbt mode: Lightdash also supports standalone Lightdash-YAML projects (no dbt), which the dbt-manifest path never covers.
Some context: in my day job I run dbt-core 1.12 + self-hosted Lightdash on BigQuery in production and am adopting Ossie files as the source of truth for metric definitions, so I have a direct, production-shaped interest in this pairing. The converter itself I'd contribute as an individual contribution. I've already started prototyping the export direction and would generalize that work here, keeping the export mapping consistent with how translateMetricFlowMetrics maps things in Lightdash core.
I'm interested in contributing a bidirectional converter (osi_to_lightdash.py / lightdash_to_osi.py) following the "Contributing a New Converter" steps (stable vendor_name for custom_extensions, both directions, tests off the TPC-DS example, a README documenting unsupported features), and aligned with the ongoing converter standardization discussed on dev@ (package named apache-ossie-lightdash, uv-based packaging).
Before I go further: would a Lightdash converter be welcome in this repo? And is there anything you'd want me to keep in mind on approach or scope — especially with respect to the converter standardization work in flight?
Thanks!
Hi all 👋
I'd like to gauge interest in adding a converter between Ossie and Lightdash's semantic definitions under
converters/.Lightdash is an open-source BI platform built on top of dbt. Its semantic layer lives in the dbt project itself: dimensions and metrics are declared per-column in dbt
schema.ymlfiles undermeta(e.g.meta.dimension: {label, type}andmeta.metrics.<name>: {type: sum | count | ... | number, label, sql}with${TABLE}.columnreferences). Tables are dbt models — conceptually close to Ossie's datasets / fields / metrics, which makes it a natural fit for a hub-and-spoke converter. Lightdash is a member of the Ossie coalition, but there is no converter for it yet.Worth noting upfront: Lightdash itself just shipped a first cut of native MetricFlow support in the CLI — no dbt Cloud required (lightdash/lightdash#19071, implemented in lightdash/lightdash#25478, released 2026-07-14).
lightdash deploynow readssemantic_models/metricsfrom the dbt manifest and translates the supported subset (simple metrics andcreate_metricmeasures) into Lightdash metrics, explicitly citing OSI/MetricFlow as the single source of truth it enables. I see a converter here as complementary to that native direction rather than overlapping with it:metametrics need a migration path into Ossie. The native dbt path doesn't cover that.format,round,groups, ...) and the native translation currently skips ratio / derived / filtered metrics. A converter can preserve all of that viacustom_extensionswith a stablevendor_name: lightdash.Some context: in my day job I run dbt-core 1.12 + self-hosted Lightdash on BigQuery in production and am adopting Ossie files as the source of truth for metric definitions, so I have a direct, production-shaped interest in this pairing. The converter itself I'd contribute as an individual contribution. I've already started prototyping the export direction and would generalize that work here, keeping the export mapping consistent with how
translateMetricFlowMetricsmaps things in Lightdash core.I'm interested in contributing a bidirectional converter (
osi_to_lightdash.py/lightdash_to_osi.py) following the "Contributing a New Converter" steps (stablevendor_nameforcustom_extensions, both directions, tests off the TPC-DS example, a README documenting unsupported features), and aligned with the ongoing converter standardization discussed on dev@ (package namedapache-ossie-lightdash, uv-based packaging).Before I go further: would a Lightdash converter be welcome in this repo? And is there anything you'd want me to keep in mind on approach or scope — especially with respect to the converter standardization work in flight?
Thanks!