Support Omni relationships file, topics, and richer field metadata#205
Open
nicosuave wants to merge 3 commits into
Open
Support Omni relationships file, topics, and richer field metadata#205nicosuave wants to merge 3 commits into
nicosuave wants to merge 3 commits into
Conversation
…data
The Omni adapter targeted a pre-"relationships-file" era: running it on a
current real export (tests/fixtures/omni/estore) produced 6 models but 0
relationships and 0 topics.
Parsing:
- Read a global relationships.yaml/.yml as a bare top-level list of joins
(current Omni), alongside the existing nested relationships: key in model.yaml.
- Read topic files (*.topic.yaml): record base_view/label/joins on graph.topics
and realize their nested joins as relationships.
- Discover views as *.view.yaml (Omni's filename convention) and name them by
Omni's {schema}__{table_name} reference convention so joins and topics resolve.
Fields:
- Add assumed_many_to_one (maps to many_to_one, flagged in metadata).
- Map extended aggregate types: median, median_distinct_on, sum_distinct_on,
average_distinct_on (to the closest Sidemantic aggregation); percentile and
list parse as custom-SQL measures with the original type kept in metadata.
- Support filter operators beyond is/greater_than_or_equal_to (not, greater_than,
less_than(_or_equal_to), contains, starts_with, ends_with, between) with
type-aware value quoting.
- Preserve dimension/measure metadata: format, synonyms, all_values,
sample_values, suggestion_list, bin_boundaries, order_by_field, timeframes.
- Support multiple timeframes per time dimension (first sets base granularity,
full list becomes supported_granularities).
The old nested-format fixture (tests/fixtures/omni/model.yaml) and all prior
behavior remain supported.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eea843e791
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
The Omni relationship parser extracted on_sql keys positionally: the
from_view column always became foreign_key and the to_view column always
became primary_key. That is correct for many_to_one, but Sidemantic
interprets primary_key as the local key and foreign_key as the related
key for one_to_many/one_to_one, so e.g. customers one_to_many orders on
${customers.id} = ${orders.customer_id} compiled to the reversed,
invalid join customers.customer_id = orders.id.
Make _keys_from_on_sql cardinality-aware and mirror the same direction
logic in _export_relationships so import/export round-trips stay
consistent. Add regression tests covering key extraction, the compiled
join condition, and export round-trip with distinct key names on each
side.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c6678eec45
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Do not map sum_distinct_on/average_distinct_on/median_distinct_on to a plain sum/avg/median: those collapse the per-key dedup and overcount on fan-out. Leave agg unset so they parse as custom measures with the original aggregate_type and custom_primary_key_sql preserved in metadata. Name schema-less views by their file stem instead of table_name so relationships and topics that reference the view name attach instead of being dropped when table_name differs from the file name.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What changed
The Omni import adapter (
sidemantic/adapters/omni.py) targeted a pre-"relationships-file" era of Omni. Running it on a current real export (tests/fixtures/omni/estore, sourced fromvbalalian/estore-analytics, MIT) produced 6 models but 0 relationships and 0 topics. This brings the adapter up to date with the current Omni export format.Parsing
relationships.yaml/.ymlas a bare top-level list of joins (current Omni), in addition to the existing nestedrelationships:key insidemodel.yaml(older exports).*.topic.yamlfiles. Each topic'sbase_view,label,description, and flattenedjoined_viewsare recorded ongraph.topics, and its nested joins are realized as relationships from each parent view to its joined views.*.view.yamlfiles and name each view by Omni's reference convention{schema}__{table_name}(e.g.omni_dbt_marts__dim_users) when no explicitname:is present, so relationships and topic joins resolve against the correct model keys. An explicitname:still wins.Fields
assumed_many_to_onerelationship type (maps tomany_to_one, flagged inmetadata).median,median_distinct_on,sum_distinct_on,average_distinct_onto the closest Sidemantic aggregation;percentileandlistparse as custom-SQL measures with the originalaggregate_typepreserved inmetadata.is/greater_than_or_equal_to:not,greater_than,less_than,less_than_or_equal_to,contains,starts_with,ends_with,between, with type-aware value quoting (numbers/booleans unquoted).format,synonyms,all_values,sample_values,suggestion_list,bin_boundaries,order_by_field,timeframes.timeframesper time dimension: the first sets the basegranularity, the full list becomessupported_granularities.Field names verified against docs.omni.co.
Backward compatibility
The old nested-format fixture (
tests/fixtures/omni/model.yaml) and all prior dimension/measure/relationship/roundtrip behavior remain supported and green.Tests
tests/adapters/omni/test_estore.pyupdated to the canonical view names, with new assertions for the relationships file, topics (base view, labels, nested-join flattening), and dimension/measure metadata.tests/adapters/omni/test_parsing.pyadds coverage for extended aggregate types, all new filter operators, multiple timeframes, a bare global relationships file (includingassumed_many_to_one), and topic-to-relationship realization.*.view.yamlfiles now compile (named without a.in the model name).Known limitations
graph.topicsand as realized relationships; there is no first-classTopicmodel in the core graph.percentile/listaggregations have no native Sidemantic equivalent, so they are carried as custom-SQL/metadata rather than a typed aggregation.