Comment on page
Limitations & workarounds
One of fundamental limitations of Snowflake is lack of transaction support for DDL commands. All DDL commands are executed 1-by-1 and are committed immediately.
In practice, it means that only some DDL commands might be executed, and the object schema will be stuck somewhere in between the original state and desired state described in config.
All object management tools are affected by this problem, but SnowDDL is generally in better position. You may fix technical issues and restart it any number of times, and SnowDDL will do its best to "repair" the object schema and bring it to the final state.
Please make sure to always keep & check SnowDDL execution logs and detect warnings early.
Renaming is currently not supported. Full object names are used as unique identifiers to match configuration entries with existing objects in Snowflake account.
For PROD it's a bit more tricky. As a workaround, we suggest to create a file with "release notes" for each release describing actions which should be performed manually.
Manual renames should be applied before SnowDDL "apply" command.
Also, it is highly recommended to avoid
--apply-unsafeoption for PROD and review all "unsafe" changes manually. It will help to prevent potential loss of data even if release engineer forgets to apply renaming prior to SnowDDL launch.
As soon as Snowflake improves this situation, the SnowDDL will support tags.
Snowflake has a fundamental limitation related to policies. In certain cases policy has to be re-created entirely from scratch.
When this happens, old policy has to be detached from all associated objects first, and new policy has to be reattached to all objects afterwards. It opens the opportunity for potential race condition, when users are able to access objects "unprotected" by policy.
In order to mitigate this problem, it is advised to have a small "maintenance" window when business users cannot login and access protected objects at all. And you should apply changes to existing policies only during this window.
Alternatively, basic secure
VIEWSwith checks on
CURRENT_ROLE()might be a better option to achieve the same result.
Snowpark and UDF functions are currently in a very active development by Snowflake. There are many "preview" and "undocumented" features.
The reasons are following:
- it helps to improve clarity by storing format options in one object type only;
- it helps to reduce duplication of format options in config;
- it helps to reduce complexity of resolvers, especially when it comes to edge cases;