Changes between Initial Version and Version 3 of Ticket #25945


Ignore:
Timestamp:
Jan 3, 2016, 7:03:19 AM (8 years ago)
Author:
Jarek Glowacki
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #25945

    • Property Summary Unabled to refer to partially-run squashed migrations in newer migrations. → Makemigrations referring to squashed migrations
    • Property Triage Stage Unreviewed → Accepted
    • Property Keywords make squash migrations added; squashmigrations removed

  • Ticket #25945 – Description

    initial v3  
    1 From Django docs:
    2 "These files are marked to say they replace the previously-squashed migrations, so they can coexist with the old migration files, and Django will intelligently switch between them depending where you are in the history. If you’re still part-way through the set of migrations that you squashed, it will keep using them until it hits the end and then switch to the squashed history, while new installs will just use the new squashed migration and skip all the old ones."
    3 
    4 However there seems to be a caviot in that you can't refer to partially squashed migrations.
    5 Example:
    6 
     1Consider the migration tree defined by:
    72{{{
    83my_app/migrations/
    … …  
    138}}}
    149
     10If we try to make `0003` depend on `0001_initial_squashed_0002_blah`, then we get a NodeNotFoundError if the database is only up to `0001_initial`: it is currently in the 'unsquashed reality' in which `0001_initial_squashed_0002_blah` does not exist. Creating new databases from this setup does not raise any problems, nor does running the migrations on databases that aren't part-way through a squashed migration series since these will live in the 'squashed reality'.
    1511
    16 If we try to make 0003 depend on 0001_initial_squashed_0002_blah, then we get a NodeNotFoundError if the database is only up to 0001_initial: it has 'intelligently switched' to the unsquashed reality in which 0001_initial_squashed_0002_blah does not exist.
     12If we try to make `0003` depend on `0002_blah`, then things work fine in all cases.
    1713
    18 Conversely if we try to make 0003 depend on 0002_blah, then we get a NodeNotFoundError when trying to create a new database: it has 'intelligently switched' to the squashed reality in which 0002_blah does not exist.
     14However `makemigrations` chooses to point newly created migrations at the squashed migration `0001_initial_squashed_0002_blah` rather than the last of the unsquashed ones `0002_blah`, causing the problem described above and making it unobvious that new migrations should still point at the old replaced migrations up until the point at which the squashed migrations get transitioned to normal migrations.
    1915
    20 Proposed solution: Use
     16Proposed solution:
    2117
    22 {{{
    23 dependencies = [('my_app', '0001_initial_squashed_0002_blah'),]
    24 }}}
     18Fully support listing the dependency both ways, as `0001_initial_squashed_0002_blah` and as `0002_blah`. For cases where the migration tree is in the unsquashed reality and thus does not contain `0001_initial_squashed_0002_blah`, have it inspect the 'replaces' list in `0001_initial_squashed_0002_blah.py`, pick out the most recent migration (ie `0002_blah`) and use that instead.
    2519
    26 and for cases where the migration tree does not contain 0001_initial_squashed_0002_blah, have it inspect the 'replaces' list in 0001_initial_squashed_0002_blah.py, pick out the most recent migration (ie 0002_blah.py) and use that instead.
    27 I'm happy to implement this myself if given the thumbs up for the proposed approach.
     20Another (perhaps cleaner, yet less clear) solution:
     21
     22Have `makemigrations` not point newly created migrations at squashed migrations, but rather at the squashed migrations' last dependency. This would solve the issue with `makemigrations` automatically creating problematic migrations. It would be cleaner as there'd only be one ''correct'' migration to point to, however it could result in confusion for people manually creating their migrations and pointing them at the wrong thing.
Back to Top