Ideas for migrations squashing improvements

[Piotr Maliński]

I made some tricky migration squashing in few projects recently. It works but still could be made better.

1. squashed migrations could have explicit flag indicating that it's a squash-initial migration. More complex squashes or optimizing squash can lead to problems when it will not fake but try to apply on existing database. Global --fake isn't a handy solutions for some deployment solutions. Or just fake every 0001* migration if any other 0001* migration was applied for given app in the past.
2. there could be a "resquash" option that would not make a squash of a squash but just optimize operations if possible for given squash (application with one migration that is a squash).
3. there could be a "testmigrations" command/option that would try to migrate everything on a test database (or just given application with dependencies) - similar to running some test just to get the migrations going.
3a. As a bonus - check if database schema is the same when migrated with old squash versus new optimized squash.

[Steve Jalim]

Amen to 3 and 3a - that's been proving one of the fiddliest aspects when there are lots of migrations to squash - trial-end-error checking of how many you can get away with squashing in one go while avoiding dependency issues from other apps

[Piotr Maliński]

It should allow squash all migrations of one app without any dependencies issues. Squashing may have problems if a model was created and later removed or when removing RunPython/SQL operations or when reordering operations to make the optimizer merge them into less operations (like getting bad order for FK, M2M operations).

[Steve Jalim]

Yep, the issue I've been having is squashing more than one app. Once I've got my head around it, i'll write it up and poss submit a documentation ticket to help

--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/vtf-4II-rEo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/31f44414-b1f6-4451-810e-6505deb1db9e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Piotr Maliński]

I do squash one app at a time:

- squash and commit
- remove old migrations, "replaces", and fixing names in dependencies - and commit
- optimize squash: remove RunPython/RunSQL, then play with operations order to merge all possible operations - and commit optimized version

The problem is that it works for a clean DB but for existing playing with dependencies names etc makes squashes not recognizable as squashes and thus database errors as things exist.