Fix spurious DROP TABLE in stamp --sql to base - #1836
Closed
Gooh456 wants to merge 1 commit into
Closed
Conversation
MigrationContext.run_migrations() dropped the alembic_version table whenever --sql mode ended with zero heads, including for the stamp command going to "base". Non-sql operation never drops the version table, only the --sql code path did. That mismatch produced a bare DROP TABLE statement with no matching CREATE for a plain "alembic stamp --sql base" that starts from no assumed heads. Remove the DROP. This also affects downgrade --sql to base which had the same unconditional drop; updated the existing test for that to match and added a regression test for the stamp case. Fixes: sqlalchemy#1822 Signed-off-by: Kyue <164024549+Gooh456@users.noreply.github.com>
Member
|
dupe of #1823 |
Author
|
ah, missed #1823. same fix basically, no worries, all good closing this one. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Fixes #1822.
alembic stamp --sql baseemits a bareDROP TABLE alembic_versionwith no matchingCREATE TABLEanywhere in the output. Real (non-sql) stamp never drops the version table, it only ever gets created, never dropped.Root cause is in
MigrationContext.run_migrations()(alembic/runtime/migration.py). At the end of the method there's an unconditionalif self.as_sql and not head_maintainer.heads: self._version.drop(...). This fires whenever an offline SQL script ends with zero heads, whether that's from stamp or from downgrade/upgrade steps that walk down to base. zzzeek confirmed on the issue this was a coding mistake from way back, added for --sql mode without checking that non-sql mode never does this.Fix just removes that block so --sql output matches what actually happens against a real database.
This also changes
downgrade --sql <rev>:baseoutput, since it shares the same code path and had the same bug (there was an existing test,test_version_to_none, that was actually asserting the buggy DROP was present). Updated that test to assert no DROP, and addedtest_sql_stamp_to_base_no_dropfor the stamp scenario from the issue.Ran the full
tests/test_command.py(116 tests) plustest_version_traversal.py,test_environment.py,test_offline_environment.pylocally, all green.