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. -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. 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/8774b69f-ce5b-45b5-a139-f1502d713ac6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
