I'm not sure about the solution you mentioned, but the problem you mention is one that I definitely do deal with. At my work we have been happy with using a "safe" migrate command that only runs migrations that are marked as safe to run before the deployment happens, to address exactly this kind of scenario. You still need to make sure you don't mix stuff in the same migration that delete and add a column, for example, but it makes the process much easier, and we've been able to add the safemigrate command to our regular automated deployments. The full migrate then only runs when manually triggered, to deal with removing columns, etc.
You can check out our repository. We've been pretty happy with how it's working for us. https://github.com/aspiredu/django-safemigrate On Mon, Jun 24, 2019 at 8:15 AM Matthieu Rudelle <m.rude...@artmyn.com> wrote: > Hi there, > > I can't find any previous ticket proposing a solution to this problem so > here are my findings: > > **Use case**: > When using continuous delivery several versions of the code can be running > in parallel on se same DB. Say for instance that release 2.42 is in > production, 2.43 is about to be rolled out and in this release one field > (say ''MyModel.my_unused_field'') is not used anymore and was removed. > Before rolling out 2.43 the DB is migrated and column ''my_unused_field'' > of ''MyModel'' is removed. This makes 2.42 crash saying that one column is > not found even though 2.42 does not use the field anywhere in the code. > > **Temporary solution**: > Do not makemigrations until de 2.44 release, but it does not scale well > with many contributors and CI tools (doing their awesome job of making sure > migrations and models are in sync) will complain. > > **Proposed solution**: > Have a ''disabled'' param on Field. When activated this field is not > fetched from the DB but replaced by a hardcoded value. > In our use case, ''disabled'' is added at the 2.42 release, then when 2.43 > rolls out and migrates the DB no error is thrown. > > **Refs**: > - django-users discussion: > https://groups.google.com/forum/#!topic/django-users/HY_6rZZ0Kk8 > - the same problem discussed in this article, but with a slightly > different solution: > https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist > (third item in the wishlist) > - Previous django-developpers discussion: > https://groups.google.com/d/msg/django-developers/5ofrxeLT95E/XhppgA_KAQAJ > > What do you guys think? > > -- > 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/637c3542-c5bd-4493-8b12-44eb61f34a68%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/637c3542-c5bd-4493-8b12-44eb61f34a68%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CABpHFHSa4hXVrp7M2MWLcsPXSRnCnvhMQ%3D8D3q1Rg8AsAXU4Cw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
