Comment on page
You may use one configuration for multiple accounts. You may repair problems caused by human errors, incorrect manual interventions, unexpected bugs, system outages, etc.
SnowDDL can revert object schema to any point in the past. You may simply checkout previous version of configuration from Git and apply it with SnowDDL.
Lack of option to revert changes is one of the biggest problems of imperative-style object management tools. It does not exist in SnowDDL.
Most changes to Snowflake table structure requires full re-creation of table and micro-partitions with data. For large tables it may incur significant additional costs.
But some changes are possible with ALTER TABLE ... ALTER COLUMN statement, which executes instantly and costs nothing. SnowDDL detects if it is possible to use ALTER TABLE before suggesting costly CREATE OR REPLACE TABLE ... AS SELECT.
New columns can be added and some data types can be changed instantly, without full table rewrite and at no extra cost.
SnowDDL offers a well thought 3-tier role hierarchy model. It is easy to understand, largely automated and requires minimal configuration. Also, it is crystal clear for security officers and external auditors.
GRANTS will no longer be a problem when organization complexity grows.
Views may become invalid when underlying objects were changed. SnowDDL detects such views using a free
.describe()call, and re-creates such views if necessary.
You'll get less complaints from users about invalid views. There is no need to maintain a separate script to fix views.
"Safe" queries can be applied and reverted with little to no risk (e.g.
CREATE). "Safe" queries usually do not require code review and can be applied immediately.
"Unsafe" queries may potentially cause loss of data or security issues (e.g.
DROP). "Unsafe queries" usually do require more attention.
This classification helps to manage code review process better, but it is optional.
You decide which DDL categories to "apply" immediately and which categories to "suggest" for manual review and manual application by
ACCOUNTADMINlater. SnowDDL will not accidentally DROP your database, unless you explicitly allow it to happen.
Multiple independent versions of the same configuration can be applied to one Snowflake account using env prefix. Unique prefix will be added to name of each account-level object, which allows multiple developers to work on the same code simultaneously without conflicts.
It is also helpful for automated testing, when each set of tests will be executed in a separate "environment".
For example, you have a production database called
BOOKINGS. Alice can create her own dev copy called
ALICE__BOOKINGS, and Bob can create his own dev copy called
BOB__BOOKINGS. Alice and Bob will never clash during development. Such "environments" can be created and destroyed instantaneously at any time.
Different object types are resolved sequentially. But objects of the same type are resolved in parallel. It provides great performance for configurations with large number of objects, but it also simplifies dependency management.
All views are created after all tables. All tables are created after all schemas. Only rare dependencies within the same object type should be maintained (e.g. view depends on another view).
Recently, Snowflake introduced Snowpark and UDF functions written in Java, Scala, Python. Such functions may rely on external packages and libraries, which should be uploaded to internal stages. Changes in packages should be synchronised with changes in UDF function code, and SnowDDL can do it for you using special object type