Replies: 1 comment
-
There's also a dev/prod story here as well. Having many dev/staging environments, one prod environment, where each environment lives in a single schema. This is a common pattern that's functionally impossible for Terraform to handle today, especially when you consider resource ownership. Titan is probably the best tool to achieve schema-level isolation for dev/prod environments, so making this work out of the box is critical. SnowDDL is the only other Snowflake tool that facilitates schema-level isolation the right way. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
When Titan prepares a config for planning and execution, it attempts to resolve the database and schema of every resource. Titan should make it easier for users to write configs by supporting "schema-less" configs: blueprints that only include schema-scoped resources with zero database or schema references.
Users want to write a single Titan config that will be executed across many schemas. Each execution would use a different service role that owns the schema.
Today Titan partially supports this with session default scope. When a database connection includes a default database/schema (either via connection string or user defaults) Titan will implicitly add those as resources to the dag. When "parentless" resources are found, Titan will assume the user wants those resources to live inside the implicit database/schema. This feature is all done implicitly, doesn't have any user-accessible control, and is focused on single database configs, not single schema.
Titan should provide an explicit user flag on Blueprint to handle this use case. There could be flags for single-database or single-schema, or there could be a more abstract "scope" flag. This flag would activate Blueprint conformance rules (eg only schema-scoped resources) and trigger special scope resolution.
There's also maybe an opportunity for Titan to assist with creation of the service role like command line generation.
There's potentially some overlap with modules, but I suspect that modules will want to specify a scope (scope bound or the scope of the module) that makes this a separate feature to build.
Beta Was this translation helpful? Give feedback.
All reactions