Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow configuration of the PUBLIC schema #306

Closed
wesleyhillyext opened this issue Nov 19, 2020 · 5 comments
Closed

Allow configuration of the PUBLIC schema #306

wesleyhillyext opened this issue Nov 19, 2020 · 5 comments
Labels
feature-request Used to mark issues with provider's missing functionalities

Comments

@wesleyhillyext
Copy link

It currently does not appear possible to define a "snowflake_schema" resource for a database's PUBLIC schema, which meaning that schema cannot be configured in Terraform.

A "snowflake_database" resource creates a database, complete with a PUBLIC schema. So an attempt to add a "snowflake_schema" resource for the PUBLIC schema results in an error like 'MY_DATABASE.PUBLIC' already exists on apply.

It may be possible to do a terraform import on a PUBLIC schema and then configure it, but even if that works it still leads to a manual process of initially applying without the "snowflake_schema", then importing state, then adding the "snowflake_schema" back in and applying again. That workaround gets even worse if you have multiple databases configured with a helper module and want to add one more database.

If there's not already a solution to this problem, I'm not sure what the best approach would be. Maybe the "snowflake_schema" resource could special-case the PUBLIC schema so that it checks if it already exists, and performs ALTER SCHEMA operations instead of CREATE SCHEMA, even if the schema is not in the Terraform state yet.

@wesleyhillyext wesleyhillyext added the feature-request Used to mark issues with provider's missing functionalities label Nov 19, 2020
@ryanking
Copy link
Contributor

I think the two options for supporting this are–

  1. rely on import - will not be great for some workflows, but has the advantage of keeping the provider code simple

  2. special-case PUBLIC and make it part of the snowflake_database resource. I think this only makes sense if there is always a PUBLIC schema. Can you delete it? Can you create a database without it? I honestly don't know. This approach would make our implementation somewhat more complicated but would make workflows like you describe simpler.

@wesleyhillyext
Copy link
Author

From the documentation on CREATE DATABASE, it says it will always create the PUBLIC schema, so it doesn't look like the database could be created without it.

@wmorin
Copy link

wmorin commented Mar 25, 2021

From the documentation, you can note also that this PUBLIC schema can be deleted.

@mackro-rocky
Copy link

Any plans to have this implemented? Importing the public schema manually doesn't seem like a great solution.

@sfc-gh-asawicki
Copy link
Collaborator

We are closing this issue as part of a cleanup described in announcement. If you believe that the issue is still valid in v0.89.0, please open a new ticket.

@sfc-gh-asawicki sfc-gh-asawicki closed this as not planned Won't fix, can't repro, duplicate, stale Apr 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Used to mark issues with provider's missing functionalities
Projects
None yet
Development

No branches or pull requests

5 participants