Migrations: Use reliable GUID to check for existence of data type when creating (closes #20592) #20604
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.
Prerequisites
Addresses : #20592
Description
This PR updates the check on whether a data type already exists before creating in a migration to use the GUID rather than the integer ID. In Cloud, with Deploy, there'll be the change of a restored environment creating the data types from the
.udafiles with a different ID than the one we expect when they are created on new installs or migrations - which then causes a bug as per the linked issue when the migration attempts to create them again.I've resolved this by using the GUID which will be the same across all environments and installations.
Testing
You can test the migration by rolling back a current database to an earlier state with the following SQL, such that on start up the migration will run again - this will confirm that the creation is skipped still if the data types already exist.