W dniu sobota, 5 listopada 2016 19:57:38 UTC+1 użytkownik Aymeric Augustin napisał: > > 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. >
That's the main problem we're facing. I'm currently leading a project that predates dinosaurs and when it was switched from South to Django, all the data migrations were just carried over from the old code. They are holy gifts from the elder gods and are rich with eldritch symbols. Nobody wants to have to copy and paste them every month or so when we decide to redo all of the migrations. There's also the problem of having many long-running (weeks to months) feature branches that make it hard to find a point in time where all migrations can be safely discarded. I can also imagine it's much harder to redo initial migrations in projects where two-way relations exist between certain applications. Cheers, -- 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/88ed6c68-1732-49bf-8d6b-3c190729472a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
