Supported object types in DCM Projects

The DEFINE statement is a special command used exclusively in DCM project definition files. Its syntax is similar to the CREATE OR ALTER command, but with the following key differences:

  • The order and location of DEFINE statements don’t matter. Snowflake collects and sorts all statements from all definition files during project execution.

  • If you remove a DEFINE statement that was previously deployed, Snowflake drops the corresponding object the next time you deploy the project. The same applies to GRANT and ATTACH statements that are removed after being previously deployed.

  • Only a subset of Snowflake object types are supported.

  • All objects must be defined with a fully qualified name (database.schema.object_name).

  • References to other objects must with fully qualified names.

The following object types are natively supported in DCM Projects definition files with the DEFINE, GRANT, or ATTACH statements.

Database

🚫 Unsupported changes:

Schema

🚫 Unsupported changes:

Table

🚫 Unsupported changes:

  • Any CREATE OR ALTER limitation, including the following operations:

    • Renaming tables

    • Renaming columns

    • Reordering columns

    • Changing column types to incompatible types

    • Adding search optimization to a table or columns

    • Adding tags and policies to a table or columns

Dynamic table

✅ Supported changes:

Without a full refresh:

  • Warehouse

  • Target-lag

With re-initialization or a full refresh:

  • Refresh mode

  • Any changes of the body including:

    • Dropping columns

    • Adding columns at the end

⚠️ Immutable arguments:

  • INITIALIZE

🚫 Unsupported changes:

View

🚫 Unsupported changes:

Internal stage

✅ Supported changes:

  • Directory table

  • Comment

⚠️ Immutable attributes:

  • Encryption type

Warehouse

⚠️ Immutable attributes:

  • INITIALLY_SUSPENDED

Role and Database Role

🚫 Unsupported types:

  • Application Role

Grant

🚫 Unsupported GRANT types:

  • APPLICATION ROLE grants

  • CALLER grants

Note

When removing a GRANT OWNERSHIP statement that was previously deployed, DCM Projects attempt to use the current owner role to grant the ownership back to the DCM project owner. If the project owner role doesn’t hold the object’s owner role, then ownership needs to be transferred back manually outside of DCM Projects.

DCM Projects is only aware of grants that were defined and deployed through DCM Projects. Any grants that were added outside of DCM Projects coexist, and DCM Projects do not remove them.

Data metric function

Data metric functions (DMFs) let you define data quality expectations and attach those expectations to tables. You can select from existing system DMFs or write your own user-defined data metric functions (UDMFs). You can then attach them to tables, views, and dynamic tables with a many-to-many relationship. For more information, see Use SQL to set up data metric functions.

To attach data metric functions, you first need to add a DATA_METRIC_SCHEDULE to each table, dynamic table, or view definition. For example: DATA_METRIC_SCHEDULE = TRIGGER_ON_CHANGES. The TRIGGER_ON_CHANGES schedule is not available for views.

The user-defined names of expectations must be unique per project and attachment.

Defining expectations is optional, but recommended, when attaching DMFs to table columns. Attached DMFs without set expectations aren’t considered when running EXECUTE DCM PROJECT <my_project> TEST ALL.

✅ Supported changes:

  • Defining UDMFs (user-defined data metric functions)

  • Attaching system DMFs and UDMFs to tables, views, or dynamic tables inside and outside a DCM project

  • Defining data expectations for table columns

Example:

An example of defining a UDMF:

DEFINE DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD(
  TABLE_NAME TABLE(
    COLUMN_VALUE number
  )
)
  RETURNS number
AS
$$
  SELECT
    MAX(COLUMN_VALUE) - MIN(COLUMN_VALUE)
  FROM
    TABLE_NAME
  WHERE
    COLUMN_VALUE IS NOT NULL
$$;

An example of attaching a system DMF with an expectation:

ATTACH DATA METRIC FUNCTION SNOWFLAKE.CORE.MIN
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION MIN_10_ITEMS_INVENTORY (value > 10);

An example of attaching a UDMF with an expectation:

ATTACH DATA METRIC FUNCTION DCM_DEMO.TESTS.INVENTORY_SPREAD
  TO TABLE DCM_PROJECT_{{db}}.RAW.INVENTORY
  ON (IN_STOCK)
  EXPECTATION EVEN_ITEM_INVENTORY (VALUE < 50);

To see all available system DMFs, query SHOW DATA METRIC FUNCTIONS IN DATABASE SNOWFLAKE.

Task

  • When definition changes are deployed for a task that is already started, Snowflake automatically suspends that task (or its root task) temporarily, applies the change, and then resumes it again.

  • Newly deployed tasks are suspended by default.

🚫 Unsupported changes:

Limitations in CREATE OR ALTER TASK statements. See CREATE TASK for more information.

SQL function

🚫 Unsupported changes:

Limitations in CREATE OR ALTER statements. See CREATE FUNCTION for more information.

Tag

🚫 Unsupported attributes:

  • Propagate

Attaching tags, masking policies, and row access policies (unsupported)

Tags, masking policies, and row access policies cannot be added to DCM Projects table column definitions.

  • You can attach masking and row access policies manually outside of DCM Projects.

  • DCM Projects definitions for table objects ignore any attached masking or row access policies. They are not revoked by redeploying table definitions, even when those definitions do not contain the policies.