Add a Lightdash converter
- Dominant language
- Python
- Stars
- 2.1k
- Forks
- 267
- Avg merge
- 4d 20h
- Merged PRs (30d)
- 24
Description
Hi all 👋
I'd like to gauge interest in adding a converter between Ossie and **Lightdash**'s semantic definitions under `converters/`.
[Lightdash](https://github.com/lightdash/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.: {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!
Contributor guide
Research direction
Start by reviewing the converter conventions under `converters/` and the “Contributing a New Converter” steps. The proposed entry points are `osi_to_lightdash.py` and `lightdash_to_osi.py`; use the TPC-DS example for tests and add a README documenting unsupported features. Confirm the converter standardization scope with maintainers before proceeding.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- data, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100