state that snowflake_database var does not alter where change history table is created #153
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Happy to alter the wording on this. I assumed that the snowflake_database var would set the database being used in the context of the connection, as I'm used to SMO and ADO.NET, and probably other people used to those libraries would make the same assumption. |
sfc-gh-tmathew
requested changes
Nov 2, 2023
There was a problem hiding this comment.
@RichieBzzzt Please make the correction and resubmit for review.
| @@ -171,7 +171,7 @@ The Jinja autoescaping feature is disabled in schemachange, this feature in Jinj | |||
|
|
|||
| ## Change History Table | |||
|
|
|||
| schemachange records all applied changes scripts to the change history table. By default schemachange will attempt to log all activities to the `METADATA.SCHEMACHANGE.CHANGE_HISTORY` table. The name and location of the change history table can be overriden by using the `-c` (or `--change-history-table`) parameter. The value passed to the parameter can have a one, two, or three part name (e.g. "TABLE_NAME", or "SCHEMA_NAME.TABLE_NAME", or "DATABASE_NAME.SCHEMA_NAME.TABLE_NAME"). This can be used to support multiple environments (dev, test, prod) or multiple subject areas within the same Snowflake account. By default schemachange will not try to create the change history table, and will fail if the table does not exist. | |||
| schemachange records all applied changes scripts to the change history table. By default schemachange will attempt to log all activities to the `METADATA.SCHEMACHANGE.CHANGE_HISTORY` table. The name and location of the change history table can be overriden by using the `-c` (or `--change-history-table`) parameter. The value passed to the parameter can have a one, two, or three part name (e.g. "TABLE_NAME", or "SCHEMA_NAME.TABLE_NAME", or "DATABASE_NAME.SCHEMA_NAME.TABLE_NAME"). This can be used to support multiple environments (dev, test, prod) or multiple subject areas within the same Snowflake account. If you use the two part name then it will attempt to create the change history table to the 'METADATA' table, and not the database set in the ```SNOWFLAKE_DATABASE``` variable. By default schemachange will not try to create the change history table, and will fail if the table does not exist. | |||
There was a problem hiding this comment.
METADATA Database instead of table.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Minor alteration to the README to make it clear that using a two part name in the
CHANGE_HISTORY_TABLEargument will result in the METADATA database being used to store the change history table, and not the value in theSNOWFLAKE_DATABASEargument.