Add an option to squashmigrations to remove RunPython and RunSQL

[Marc Tamlyn]

Migrations (correctly) do not optimise through RunPython and RunSQL commands. However many of these commands are data mutating, rather than creating initial data, and once they have been applied to all deploys (so the original migrations files can be removed) they are no longer relevant.

It would be nice to have ./manage.py squashmigrations --no-data or similar which simply removes these operations and optimises without them.

[Tim Graham]

I had this use case when squashing migrations for some djangoproject.com work. What I did was generate a new "initial" migration (which contained only CreateModel operations instead of many AlterField operations that weren't optimized despite the fact that RunPython weren't between them) for the app and then copied the "replaces" attribute from the migration that squashmigrations generated to generate my own squashed migration. I wonder if this is a workflow we should recommend (automating it could be nice, I guess).

[Marc Tamlyn]

I think the default behaviour (not doing this) is correct, but I think it should be easy to do

[Carl Meyer]

I think this is a duplicate of #24109. They aim to solve exactly the same problem, though they propose different UI for it. #24109 proposes that a specific operation instance can be explicitly marked as elidable (in which case squashmigrations would always feel free to collapse it), whereas this ticket proposes providing an option to the squashmigrations command to automatically elide all RunPython and RunSQL migrations.

I think the proposal in #24109 is better, because whether a RunSQL/RunPython operation is elidable when squashing is really a property of the specific operation instance, not a general property of the entire migration set. For instance, in the same migration set I might have a RunSQL operation which is a pure data migration, and totally safe to elide when squashing, and another RunSQL operation which is an actual schema alteration, and not at all safe to elide. The proposal here would give me no way to handle that situation correctly.

But regardless of what UX we settle on, I don't think we need two separate tickets to track the problem and a potential solution.

Tim, I think the problem you outline is a different problem entirely (though related), and deserves its own ticket. The first question it raises is "why weren't those AlterField operations squashed; maybe that's a bug in the optimizer?" The second question it raises is a potential new feature, which is a totally different (and less safe, but more likely to result in a "clean" squashed migration) approach to squashing, where instead of taking the existing operation set and running the optimizer over it, we simply ignore the existing migration set entirely and generate a brand-new initial migration based on the current models. I think this is a new feature worth having (though its limitations would need careful documentation), but I don't think it's quite the same feature this ticket was requesting.

Closing this as dupe of #24109; feel free to open a new ticket for the "ignore existing migrations" version of squash.

[Marc Tamlyn]

Agreed the proposal in #24109 is better, I didn't find that when searching because I had no idea what elidable meant.