Drop explicit transaction from store_node_tokens_as_encrypted_value #3280
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
Migrations are executed in transactions anyway, and creating a savepoint can cause spurious failures on databases that don't support transactional DDL (like MySQL and MariaDB) when it attempts to commit a savepoint that was silently not created because there wasn't an active transaction after some DDL was executed. While a better solution might involve splitting this migration into several so each one is only DDL or only data manipulation, I don't think that can be done very easily while maintaining compatibility with existing deployments. Fixes pterodactyl#3229.
|
This might not matter since it probably affects other migrations too, but do you know if this will cause the dry-run for migrations to accidentally execute this logic? I've run into that in the past but I'm not sure how I avoided it. |
|
|
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.
Migrations are executed in transactions anyway, and creating a savepoint can cause
spurious failures on databases that don't support transactional DDL (like
MySQL and MariaDB) when it attempts to commit a savepoint that was silently
not created because there wasn't an active transaction after some DDL was
executed.
While a better solution might involve splitting this migration into several so each
one is only DDL or only data manipulation, I don't think that can be done very
easily while maintaining compatibility with existing deployments.
Fixes #3229.