SnowDDL
  • 👋Introduction
  • ðŸšĐGetting started
  • 📋Main features
  • ðŸŠĪSnowDDL vs. Declarative DCM
  • In-depth guides
    • 👓Object identifiers
    • 📐Data types
    • ðŸ“ĶObject types
    • 🎭Role hierarchy
    • 🚧Permission model
    • ðŸ”ĶOther guides
      • Administration user
      • Integrations
      • Inbound shares
      • Object OWNERSHIP
      • Safe & unsafe DDL
      • Dependency management
      • Short hash explained
      • Env Prefix explained
      • Team workflow
      • Limitations & workarounds
      • Fivetran
      • Airbyte
      • Encrypt user passwords
      • Iceberg Tables
  • Basic usage (CLI + YAML)
    • ðŸ’ŧCLI interface
    • ðŸ“ĶYAML configs
      • ACCOUNT PARAMETER
      • ACCOUNT POLICY
      • AGGREGATION POLICY
      • ALERT
      • AUTHENTICATION POLICY
      • BUSINESS ROLE
      • DATABASE
      • DATABASE ROLE
      • DYNAMIC TABLE
      • EVENT TABLE
      • EXTERNAL ACCESS INTEGRATION
      • EXTERNAL FUNCTION
      • EXTERNAL TABLE
      • FILE FORMAT
      • FUNCTION
      • HYBRID TABLE
      • ICEBERG TABLE
      • MASKING POLICY
      • MATERIALIZED VIEW
      • NETWORK POLICY
      • NETWORK RULE
      • PERMISSION MODEL
      • PIPE
      • PLACEHOLDER
      • PROCEDURE
      • PROJECTION POLICY
      • RESOURCE MONITOR
      • ROW ACCESS POLICY
      • SCHEMA
      • SECRET
      • SEQUENCE
      • SHARE (outbound)
      • STAGE
      • STAGE FILE
      • STREAM
      • TABLE
      • TASK
      • TECHNICAL ROLE
      • USER
      • VIEW
      • WAREHOUSE
    • 🏷ïļYAML placeholders
    • 📎YAML tag !include
    • 🔐YAML tag !decrypt
  • Single DB
    • ðŸĶ€Overview
  • Advanced usage (Python)
    • ⚙ïļProgrammatic config
    • 🐍Architecture overview
      • ðŸ”ĩBlueprints
      • ðŸŸĢConfig
      • 🟠Parsers
      • ðŸŸĒResolvers
      • ðŸ”īEngine
    • 🏗ïļQuery builder & formatter
  • Breaking changes log
    • 0.45.0 - March 2025
    • 0.41.0 - January 2025
    • 0.37.0 - December 2024
    • 0.36.0 - November 2024
    • 0.33.0 - October 2024
    • 0.27.0 - May 2024
  • Links
    • GitHub repository
    • PyPI package
    • YouTube tutorials
    • Changelog
    • LinkedIn profile
Powered by GitBook
On this page
  • Inheritance
  • JSON schema
  • Methods
  1. Advanced usage (Python)
  2. Architecture overview

Parsers

Parsers are used to process YAML config files into blueprints, one parser per object type.

All standard parsers are located in /parser/ directory.

Inheritance

All parsers are derived from AbstractParser class.

JSON schema

SnowDDL uses jsonschema Python library to validate YAML configs. JSON Schema for each object type is stored in the same file as parser for your convenience.

Methods

  • __init__(config: SnowDDLConfig, base_path: Path) Initialize parser with config and Path object containing path to config directory.

  • load_blueprints() Abstract method, it should be implemented by each parser class. Normally it reads YAML files, builds blueprints and adds blueprints to config.

  • parse_single_file(path: Path, json_schema: dict, callback: Callable = None) Accepts path to YAML file, JSON schema definition and optional callback function. Parses YAML file, validates it with provided JSON schema, process it using callback function. If any Exception is being raised inside callback function, it is treated as config validation error, "muted" and added to .errors property of config. If callback function was not defined, it returns processed YAML file as basic Python dict.

  • parse_schema_object_files(object_type: str, json_schema: dict, callback: Callable) Accepts name of object type (as string), JSON schema definition, mandatory callback function. Finds and parses all files of specified object type, validate each file with provided JSON schema, process each file with callback function. If any Exception is being raised inside callback function, it is treated as config validation error, "muted" and added to .errors property of config.

PreviousConfigNextResolvers

Last updated 1 year ago

🐍
ðŸŸ