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
On Thursday, May 21, 2015 at 11:08:42 AM UTC+1, Piotr Maliński wrote: > > 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/ba0832f2-51df-47e4-89e9-5c46d3ad6e29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
