Skip to content

Add Snowflake → OSI import converter (snowflake_to_osi)#163

Open
sudulakuntanithin wants to merge 1 commit into
apache:mainfrom
sudulakuntanithin:snowflake-to-osi-converter
Open

Add Snowflake → OSI import converter (snowflake_to_osi)#163
sudulakuntanithin wants to merge 1 commit into
apache:mainfrom
sudulakuntanithin:snowflake-to-osi-converter

Conversation

@sudulakuntanithin

Copy link
Copy Markdown

Closes #162.
Adds the import direction for the Snowflake converter: snowflake_to_osi_yaml_converter.py, converting Snowflake Cortex Analyst semantic view YAML into OSI. The converters/snowflake/ directory previously shipped only osi_to_snowflake (export); this completes the bidirectional pair, consistent with the converter guide and roadmap.
Mapping (verified against the official semantic view YAML spec):

tables → datasets; base_table ({database, schema, table}) → source
dimensions / time_dimensions / facts → fields (with dimension.is_time set appropriately)
Both table-level and view-level metrics → OSI top-level metrics
relationships (left_table/right_table, relationship_columns) → from/to/from_columns/to_columns
Snowflake-specific settings preserved in custom_extensions (vendor_name: SNOWFLAKE); unmapped constructs raise warnings rather than failing silently

Testing:

117 tests pass (pytest tests/), including unit, integration, and a round-trip test through the existing exporter
Output validates against osi-schema.json, including sqlglot SQL validation
CLI mirrors the existing converter: python3 src/snowflake_to_osi_yaml_converter.py -i input.yaml -o output.yaml

Notes / open questions for maintainers:

On duplicate metric names (table-level vs. derived), the converter keeps the first and warns — happy to change to name-qualification if preferred.
README updated to document both directions.

Comment on lines +594 to +606
def _warn_dropped_fields(source, context):
"""Warns about Snowflake fields that have no OSI counterpart.

These are fields that exist in the Snowflake model but should not be
dropped silently; they should be captured in custom_extensions or
explicitly warned about.
"""
# Snowflake-specific fields that don't map to OSI and weren't handled:
# - warehouse, database, schema (table-level config)
# - any other vendor-specific fields (these should be in custom_extensions now)

# For now, we don't warn about anything here since we capture all unknown
# fields in custom_extensions. The warning is implicit in the custom_extensions.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method looks empty ? Do you want to track this issue for follow up ?

Comment on lines +481 to +482
# - filters: Snowflake-specific row-level security filters
# - tags: Snowflake tags for metadata (preserved in custom_extensions as vendor-specific)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How are filters and tags mapped to OSI fields ?

@jbonofre
jbonofre self-requested a review July 14, 2026 18:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add Snowflake → OSI import converter (snowflake_to_osi)

2 participants