id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 25945,Referring to partially run squashed migrations,Jarek Glowacki,Jarek Glowacki,"Consider the migration tree defined by: {{{ my_app/migrations/ 0001_initial.py 0002_blah.py -> dep on 0001_initial 0001_initial_squashed_0002_blah.py -> replaces 0001_initial and 0002_blah 0003_ohnoes.py -> dep on ???? }}} 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 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'. If we try to make `0003` depend on `0002_blah`, then things work fine in all cases. However `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. Proposed solution: Fully support listing the dependency both ways, as `0001_initial_squashed_0002_blah` and as `0002_blah`, using fancy logic to ensure valid references to inapplicable migrations are appropriately rerouted. [https://github.com/django/django/compare/master...jarekwg:ticket_25945 / Patch] [https://github.com/django/django/pull/5939 / Pull Request]",Bug,closed,Migrations,dev,Normal,fixed,make squash migrations partially run dependencies,,Ready for checkin,1,0,0,0,0,0