You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may happen many times that a version with a damaged migration will be released.
If we improve the migration, on a few systems we may have a conflict with an incompatible md5 checksum - this is sometimes normal.
But it is also very tedious.
What do you think that if a situation such as a checksum mismatch is detected, the <bad_md5> .cancel.descr.sql file is searched and run, which will automatically roll back such a damaged migration.
If the file is not found, a migration error will occur as now and the migration will be aborted.
The text was updated successfully, but these errors were encountered:
I don't really have much of an opinion on how to deal with this issue. I personally don't use the checksum functionality.
Then again I also treat migrations as immutable. If a change needs to happen its always written as another up/do migration, and I don't really bother with the down/undo scripts.
It may happen many times that a version with a damaged migration will be released.
If we improve the migration, on a few systems we may have a conflict with an incompatible md5 checksum - this is sometimes normal.
But it is also very tedious.
What do you think that if a situation such as a checksum mismatch is detected, the <bad_md5> .cancel.descr.sql file is searched and run, which will automatically roll back such a damaged migration.
If the file is not found, a migration error will occur as now and the migration will be aborted.
The text was updated successfully, but these errors were encountered: