Changes between Initial Version and Version 2 of Ticket #33583


Ignore:
Timestamp:
Mar 18, 2022, 10:01:28 AM (3 years ago)
Author:
Amin Shah Gilani
Comment:

Replying to Mariusz Felisiak:

Thanks for the report, this behavior was changed in d88365708c554efe3c786c3be6da1d9de916360f. However, replaces is documented and supported only for ​squashing migrations so described flow was never officially supported.

Thank you for your response. Would it then be correct to say that the migrate command needs to be updated as well to raise an error? As it stands the behavior is inconsistent. I've added existing and expected behavior to the original ticket in order to clarify this problem.

Additionally, for applications that depend on relocated migrations in third-party packages, will it be fine to update the now outdated pointer to the new location of the migration?

In the context of the example above, is this fine? 

dependencies = [
-    ('first', '0001_initial'),
+    ('alpha, '0001_initial'),
]

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #33583

    • Property Cc David Wobrock added
    • Property Component Uncategorized → Migrations
    • Property Resolution → invalid
    • Property Status new → closed
    • Property Summary Inconsistency: sqlmigrate reports a broken migration but migrate applies them → sqlmigrate crashes on replaces to nonexistent migration.

  • Ticket #33583 – Description

    initial v2  
    109109
    110110**Note:** I have a demo available to try [https://github.com/amingilani/django-bug-PoC here].
     111
     112
     113== Actual Behavior
     114
     115`sqlmirate` raises an error but `migrate` processes the migrations without a problem
     116
     117== Expected Behavior
     118
     119Both commands would consistently either raise an error on these migrations, or run without raising an error
Back to Top