Does that sound like feature-request material? It seems to me django is the good place to add this flexibility as it has exclusive access to the underlying DB.
On Tue, Jun 25, 2019 at 9:08 AM Matthieu Rudelle <m.rude...@artmyn.com> wrote: > How does the "safe" field of migrations work with other migrations related >> commands, such as squashmigrations? >> > > Squashmigrations typically targets and produces migrations that are old > enough to be assumed safe. > > >> You can check out our repository. We've been pretty happy with how it's >> working for us. https://github.com/aspiredu/django-safemigrate > > > safe-migrate is a neat solution. Although it lacks support for rollbacks: > as soon as "migrate" is run the app is stuck in the current release > > If migrations are seen as a rolling window, you want a window of X > releases (2 in our case) to play well together (minus discrepancies due to > updates to the application logic) so being able to postpone a column > removal to a later release is important. The "disabled" feature (or > anything similar to a flag written in the codebase) has this added benefit. > Squash migration would be used to squash up to but excluding the current > sliding window. > > there are similar to `alter table drop column` issue: `alter table >> rename column`, `drop table`, `rename table`. (honestly `alter table drop >> column` and `drop table` a bit different wiith `alter table remane column` >> and `rename table`) >> > > - `alter table rename column` can be reduced to `alter table add > column` and later `alter table drop column` plus some temporary update > replication implemented in the app (idem for `rename table`) > - `drop table` follow the same logic with the SQL actions delayed to a > later release > > But if you mix migrations for `alter table add column` and `alter table >> drop column` - you cannot safely apply both migrations simultaneously, and >> your proposal sounds pretty reasonable there. > > > > However if you add disabled option, then make migration, remove field, >> then make migration, then apply this changes to your environment - you will >> get same issue. So to automate deployment process and to get achievable >> result you want I think you need something more complex: deploying atomic >> changes, but for me it sounds more about deployment than django itself. >> > > As long as the columns are different these actions can happen in parallel. > The flag will just delay the DB migration to a later release and the > deployment needs this kind of flexibility from django to avoid direct > access to the DB by the deployment process. > > On Tuesday, June 25, 2019 at 7:06:38 AM UTC+2, Paveł Tyślacki wrote: >> >> there are similar to `alter table drop column` issue: `alter table >> rename column`, `drop table`, `rename table`. (honestly `alter table drop >> column` and `drop table` a bit different wiith `alter table remane column` >> and `rename table`) >> >> Look like you general flow for migration: >> 1. change code and create migrations >> 2. apply migrations >> 3. apply code for all your instances >> >> the issue in this cases I can describe: we have code that we still used. >> >> for `alter table drop column`, `drop table` next scenario works fine (as >> your temp solution too): >> >> 1. remove column/table usage from codebase >> 2. apply this code for all of your instances >> 3. apply migration with field/table removal >> >> But if you mix migrations for `alter table add column` and `alter table >> drop column` - you cannot safely apply both migrations simultaneously, and >> your proposal sounds pretty reasonable there. >> >> However if you add disabled option, then make migration, remove field, >> then make migration, then apply this changes to your environment - you will >> get same issue. So to automate deployment process and to get achievable >> result you want I think you need something more complex: deploying atomic >> changes, but for me it sounds more about deployment than django itself. >> >> >> >> >> On Monday, 24 June 2019 16:15:04 UTC+3, Matthieu Rudelle 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 a topic in the > Google Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/Gr9x2OlWYN4/unsubscribe > . > To unsubscribe from this group and all its topics, 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/59bd29b1-5de3-4239-b534-fc5146995f72%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/59bd29b1-5de3-4239-b534-fc5146995f72%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/CANP1NSz45RBwO2piYRCw42ACDdsvtSo2HNF91uUWxagQZXAC0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
