Many other db deployment tools have the ability to track the hash of a file. It's a useful feature in several use cases where it's more painful to create a new migration script vs. just updating an existing one and having the the change be detected and the script re-run. A couple common use cases I have experience:
1) A lookup list of values. Especially if you have many lists. It's easier to just maintain the list in a json/js/ts file and have the entire contents replaced when the script is run. If the lookups change, you alter the one source file and it will update the db.
2) Templates. These are typically very text heavy and in some systems have a bunch of meta properties. It may make more sense to store the template in a single file and alter that file if text is updated.
The behavior doesn't really change, you can still treat a script as immutable even if they physically are not with hash change tracking.
I'm creating this because I am submitting a pull request for this feature.
Many other db deployment tools have the ability to track the hash of a file. It's a useful feature in several use cases where it's more painful to create a new migration script vs. just updating an existing one and having the the change be detected and the script re-run. A couple common use cases I have experience:
1) A lookup list of values. Especially if you have many lists. It's easier to just maintain the list in a json/js/ts file and have the entire contents replaced when the script is run. If the lookups change, you alter the one source file and it will update the db.
2) Templates. These are typically very text heavy and in some systems have a bunch of meta properties. It may make more sense to store the template in a single file and alter that file if text is updated.
The behavior doesn't really change, you can still treat a script as immutable even if they physically are not with hash change tracking.
I'm creating this because I am submitting a pull request for this feature.