Skip to main content

Migrating to SOLE June 2025

Overview​

With the May 2025 5-latest release of SOLE (Snowflake Object Lifecycle Engine), we introduced several changes to improve consistency with Snowflake and the overall user experience. These changes include important YAML configuration changes such as adding new object parameters and altering or removing some existing ones.

This guide shows you how to update your existing SOLE configuration to ensure uninterrupted execution and successful migration to the most recent version.

Production rollout

The SOLE May release will become the 5-stable production release in June 2025.

New parameters in existing SOLE objects​

New parameter in view​

The view object now supports a new copy_grants parameter which defaults to false. Set this parameter to true in your configuration to retain the access permissions from the original view when you recreate it.

For more information and examples, check the view documentation.

New constraint types in table and hybrid table​

We added new unique and foreign_keys parameters to the Table and Hybrid Table objects. You can start setting these parameters in your YAML configuration to define relationship constraints between objects.

To set either of the new constraints, follow this syntax:

- table:
    name: SAMPLE
    unique:
      name: "UQ_CUSTOMER_EMAIL"
      keys:
        - CUSTOMER_EMAIL
        - PREFERRED_CATEGORY

The same syntax applies to both Table and Hybrid Table objects.

For more information and examples, check:

New parameter in SCIM integration​

In the SCIM Integration object, we added a new parameter named enabled. Snowflake requires this parameter and sets its default value to true to maintain compatibility. You may override it in your YAML configuration as needed.

- scim_integration:
    name: SCIM_INTEGRATION_1
    provisioner_role: "AAD_PROVISIONER"
    scim_client: "AZURE"
    enabled: false

For more information and examples, check the SCIM Integration documentation.

Breaking changes​

YAML configuration changes​

Besides the new parameters, we also made some changes to the YAML configuration structure of existing parameters. The following sections outline the changes you need to make in your YAML configuration files.

warning

You must apply these changes to your YAML configuration files to ensure compatibility with the latest version of SOLE.

Changes in the schedule parameter of task​

We updated the schedule parameter of the task object to support a more structured format. You can still set it to a cron expression or an interval in minutes, but with an updated syntax.

- task:
    name: <task-name>
    database: rel(database.<database-name>)
    schema: rel(schema.<schema-name>)
    schedule: "5 MINUTE"

To use a cron expression, you can set the schedule parameter as follows:

- task:
    name: <task-name>
    database: rel(database.<database-name>)
    schema: rel(schema.<schema-name>)
    schedule: "*/5 * * * *"

Changes in the signature parameter of row access policy​

- row_access_policies:
    name: <row-access-policy-name>
    database: rel(database.<database-name>)
    schema: rel(schema.<schema-name>)
    signature:
      EMPL_ID: "VARCHAR"
      EMPL_SAL: "VARCHAR"

Changes in the value_data_type parameter of masking policy​

- masking_policy:
    name: <masking-policy-name>
    database: rel(database.<database-name>)
    schema: rel(schema.<schema-name>)
    value_data_type: "VARCHAR"

Removed parameters in existing SOLE objects​

To stay consistent with the corresponding Snowflake objects, we removed the support of some existing parameters in SOLE. If you want to continue setting some of them, you can still do so by using SOLE hooks.

warning

These parameters will not appear in the generated resource files, even if you define them in the YAML configuration.

Removed parameter in view​

We refined the behaviour of the or_replace parameter of views. SOLE no longer explicitly supports this parameter. Instead, when you change a configuration that requires recreation, SOLE implicitly handles the CREATE OR REPLACE logic. You only need to set copy_grants to true if you wish to preserve existing grants during the recreation. This change simplifies the resource lifecycle by making the or_replace behavior implicit and context-aware.

For more information and examples, check the view documentation.

Removed parameter in resource monitor​

We no longer support the set_for_account parameter in the Resource Monitor object. In the future, we will add back the support to assign a resource monitor to the account using a different approach. In the meantime, if you want to assign a resource monitor to the account, you can do so using SOLE hooks.

Let's say you have the RESOURCE_MONITOR_1 object defined in your SOLE configuration as follows:

- resource_monitor:
    name: RESOURCE_MONITOR_1
    frequency: "YEARLY"
    start_timestamp: "2025-07-15"
    end_timestamp: "2028-07-15"
    notify_triggers:
      - 40
    suspend_triggers:
      - 50
    suspend_immediate_triggers:
      - 90

Use the following SOLE hook to assign the resource monitor to the account:

database_level_hooks:
  post_hooks:
    - command: "ALTER ACCOUNT SET RESOURCE_MONITOR = RESOURCE_MONITOR_1;"
      environment: snowflake

Check the Resource Monitor documentation for more information about the supported parameters.

Removed parameter in SAML integration​

For security reasons, we removed support for the saml2_snowflake_x509_cert parameter in the SAML Integration object. When you omit this parameter, Snowflake automatically generates it when creating an object. However, if you want to set it yourself explicitly, you can use SOLE hooks. Assuming you already have a SAML Integration object named SAML_INTEGRATION_1 defined in your SOLE configuration, your hook to set the saml2_snowflake_x509_cert should look something like this:


database_level_hooks:
  post_hooks:
    - command: "ALTER SECURITY INTEGRATION SAML_INTEGRATION_1 SET SAML2_SNOWFLAKE_X509_CERT = '{{ env.SAML2_SNOWFLAKE_X509_CERT }}';"
      environment: snowflake

Of course, you need to store the saml2_snowflake_x509_cert value in your secrets vault before referencing it in the hook.

Check the SAML Integration documentation for more information about the supported parameters.

Removed parameter in user​

The has_rsa_public_key parameter in the user object is obsolete, and Snowflake no longer supports it. Hence, SOLE no longer supports it. However, the behavior of the rsa_public_key parameter hasn't changed, so you can keep using it to set the RSA public key for the user.

Check the user documentation for more information about the supported parameters.

Last updated on