Hello, My solution is to throw away and remake all migrations on a regular basis. Then I `TRUNCATE TABLE django_migrations` and `django-admin migrate --fake`. Obviously this isn’t a great solution.
Since I work mostly on small projects with just a couple developers on staff, doing this every few months suffices to keep the run time below one minute (which is still quite annoying). There’s a risk to lose important, manually generated migrations, typically those that create indexes. I diff the schema before / after with apgdiff to avoid such problems. This is quite doable but outside the comfort zone of many developers: my clients prefer to have me do it even though I documented the steps in detail. So… yeah, it would be nice to have something more practical, even if it requires trading off some purity in the design of migrations. -- Aymeric. -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/84521630-23DC-44CF-B363-8FC913B10084%40polytechnique.org. For more options, visit https://groups.google.com/d/optout.
