Re: [PR] Add bidirectional Apache Ossie <-> Cube converter [ossie]

["MikeNitsenko (via GitHub)" <gi...@apache.org>]

MikeNitsenko commented on PR #289:
URL: https://github.com/apache/ossie/pull/289#issuecomment-5184709389

   PR #289 — reviewer note
   
   Tests: 534, or 561 with the optional Cube gate. Coverage: 97%.
   
   Layers:
   
   * Three whole models: a small one, TPC-DS (as requested by the converter guide), and one produced by the Databricks converter, where nothing was written “for Cube.” They are compared as whole documents, so any unintended change appears as a readable diff.
   * Feature matrix: one fixture per Cube feature, ten in total: case/switch dimensions, granularities, presentation metadata, measure variants, hierarchies, segments, pre-aggregations, access policies, view curation, sub_query, and computed primary key. Each fixture is a valid Cube model and is asked the same four questions: does it convert; is the Ossie output valid according to the spec; does Cube → Ossie → Cube reproduce it; and does Cube still compile the result.
   * Property tests from both ends: 60 seeds plus 150 generated cases per direction. Generating only from Cube says nothing about hand-authored Ossie, and that is the harder direction.
   * Cube itself as a gate: tools/cube_compile.js asks Cube whether what we emit actually loads. It requires a locally built Cube checkout (OSSIE_CUBE_REPO); without one, those tests are skipped, so CI is unaffected.
   * Idempotence: a second export cycle must produce the same Cube model as the first. This is the only way to catch a record that one side writes and the other reads differently.
   
   Cross-matrix (tools/interop_matrix.py): our Ossie output is run through all nine Python converters, with a report showing what each one made of it. This is what the stash reduction was measured against: 7 CUBE entries on TPC-DS instead of 41, and 2 Databricks warnings instead of 32.
   
   Databricks — both directions:
   
   * Cube → Ossie → metric view.
   * metric view → Ossie → Cube, using all three fixtures from that converter; the result compiles in Cube.
   * Full loop: metric view → Ossie → Cube → Ossie → metric view. Source, joins, dimensions, and measures come back with the same names.
   
   Snowflake: that converter is export-only, so there is no reverse path in the repository. One direction was verified: Cube → Ossie → Cortex Analyst.
   
   These interop paths are what the tests specifically pin down: which dialect an expression carries, where the primary key comes from, and whether a field has a dimension role. Each is a point where the two formats disagree and the conversion must make an explicit choice.
   
   Limitations:
   
   * Ossie cannot declare a measure as non-additive, so the fan-out risk can only be reported, not recorded in the model — issue #290.
   * A metric view does not carry a primary key, while Cube requires one on any cube with a join. It must therefore be added manually using primary_key or unique_keys. We report this using Cube’s own error message.
   * The compile gate requires a local Cube checkout, so it is skipped in CI.
   * Polaris and Salesforce are written in Java and require Maven. They are listed in the matrix as unsupported rather than being silently skipped.
   * dbt fails in the matrix because of its own CLI bug — issue #296, not ours.
   
   What I need: CI has never run on this PR because GitHub holds workflows from external contributors until a committer approves them. The PR needs a review and a CI run.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@ossie.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org