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
  • Potentially breaking changes
  • Config migration guide
  • Code migration guide
  • Any questions or problems?
  1. Breaking changes log

0.27.0 - May 2024

Previous0.33.0 - October 2024

Last updated 1 year ago

This update introduces significant changes to SnowDDL permission model.

Potentially breaking changes

  • OWNERSHIP on ALERT, DYNAMIC_TABLE, EVENT_TABLE, STAGE are now granted to corresponding schema owner role. Previously OWNERSHIP for these objects types was assigned to SnowDDL admin role.

  • New parameters were added for SCHEMA object type to support additional types of grants.

Config migration guide

  • For schemas with ALERT and DYNAMIC_TABLE objects, use new parameter owner_warehouse_usage to specify warehouses which can be used by schema owner role.

  • For schemas with ALERT and STAGE object types, use existing parameter owner_integration_usage to specify names of global integrations which can be used by schema owner role.

  • For schemas with ALERT object type, add value - EXECUTE ALERT to new parameter owner_account_grants to allow execution of alerts in schema.

  • For schemas with TASK object type, add value - EXECUTE TASK to new parameter owner_account_grants to allow execution of task in schema.

  • For schemas with ALERT, DYNAMIC_TABLE, PROCEDURE accessing data in other schemas, make sure to use existing parameter owner_schema_read to specify these schemas.

Code migration guide

  • If you use , which creates DatabaseBlueprint or SchemaBlueprint, make sure to add a new required parameter permission_model. This is how you can get default permission model, which is close to settings in previous SnowDDL versions:

    bp.permission_model = config.get_permission_model(config.DEFAULT_PERMISSION_MODEL)
  • FutureGrant object was changed. Now it accepts 4 parameters instead of 3 in the past. Parameter on was renamed to on_future, and new parameter in_parent was added, which takes DATABASE or SCHEMA object type:

    class FutureGrant(BaseModelWithConfig):
        privilege: str
        on_future: ObjectType    
        in_parent: ObjectType      -- SCHEMA or DATABASE
        name: Union[DatabaseIdent, SchemaIdent]

Any questions or problems?

Thank you!

You may create a . Please provide as much context as possible. Sample configs and logs are very helpful as well.

programmatic config
new discussion on GitHub