Skip to content

Add an Apache Superset dataset YAML converter #268

Description

@utkarshparekh

Hi all,

I would like to propose a bidirectional converter between Apache Ossie semantic models and Apache Superset dataset definitions.

Motivation

Superset provides a lightweight semantic layer around physical and virtual datasets, calculated columns, and reusable metrics. It also provides supported YAML import/export workflows and REST endpoints for dataset bundles. A converter would let teams move these definitions into Ossie for interchange with other semantic tools and publish an Ossie model back into a Superset-compatible dataset bundle.

Official references:

I searched the open and closed Ossie issues and pull requests and did not find an existing Superset converter proposal.

Proposed v1 boundary

  • Convert static Superset dataset YAML, without requiring a running Superset instance.
  • Support physical and SQL-based virtual datasets.
  • Map dataset names, descriptions, schemas, tables, columns, calculated-column expressions, temporal flags, and dataset metrics.
  • Accept and emit the documented dataset import/export bundle structure.
  • Do not include charts, dashboards, saved queries, users, roles, or database credentials.
  • Do not execute Jinja templates. Preserve template-bearing SQL or calculated expressions as Superset-specific metadata and report that they cannot be statically interpreted.
  • Preserve supported Superset-only properties in a versioned SUPERSET custom extension so semantic round-trips do not silently discard them.
  • Validate generated Ossie documents against core-spec/osi-schema.json.

Initial mapping

Superset Ossie
physical or virtual dataset dataset
table/schema or virtual SQL dataset.source and Superset extension metadata
dataset column field
calculated column SQL field.expression
temporal column field.dimension.is_time
dataset metric model-level metric with owning-dataset metadata
dataset description and column descriptions corresponding Ossie descriptions

Superset metrics are dataset-scoped, while Ossie metrics are model-scoped. On import, duplicate metric names from different datasets therefore need deterministic qualification while retaining the original name and owner. On export, the converter should use preserved owner metadata and only infer ownership from expressions when exactly one dataset is referenced.

Superset's documented dataset format does not provide an Ossie-style inter-dataset relationship graph. For an Ossie-to-Superset-to-Ossie round-trip, relationships would need to be preserved in the Superset extension or reported as unsupported rather than assigned or discarded silently.

Proposed project shape

  • Distribution: apache-ossie-superset
  • Python module: ossie_superset
  • Directory: converters/superset/
  • Static YAML parsing with an Apache-compatible YAML dependency already acceptable to the project
  • Unit fixtures covering physical and virtual datasets, calculated columns, temporal fields, metric-name collisions, Jinja-bearing expressions, and metadata restoration
  • Semantic round-trip tests in both directions
  • Optional integration validation against a local Superset instance, separate from the static runtime converter

Questions for maintainers

  1. Would this converter and the static dataset-YAML v1 boundary be welcome?
  2. Should v1 target Superset's established dataset import/export format only, or account for the newer experimental SEMANTIC_LAYERS feature separately?
  3. Is preserving Ossie relationships in a SUPERSET extension acceptable when Superset cannot represent them natively?
  4. Does the proposed Python package naming match the direction for newer converters?

If the direction is welcome, I would like to contribute the converter and first prepare a precise mapping/loss matrix and representative exported fixtures before opening a focused implementation PR for review.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions