Re: [Model, ORM] Disabling a field before actually removing it

For Info, the discussion on django-developers : https://groups.google.com/forum/#!topic/django-developers/Gr9x2OlWYN4

On Monday, June 24, 2019 at 3:01:55 PM UTC+2, Matthieu Rudelle wrote:

From the tests we conducted, even fields that are nullable and that are not used in the code require the underlying column to be present on DB. 

So as soon as the new release migrates the DB and gets rid of the column. The previous release (that is still running on this DB) complains that the table is missing with a 500.

On Monday, June 24, 2019 at 2:20:38 PM UTC+2, Vinicius Assef wrote:

I would, before everything, deploy code to stop using the field.

After that, I would make it nullable and, then, remove it from the table.

On Mon, 24 Jun 2019 at 05:32, Matthieu Rudelle <m.ru...@artmyn.com> wrote:

Yep, that's what we're planning on doing. 

It's kind of hacky though, it requires to warn all contributors to not makemigrations or to manually remove the field removal from the generated migration until the new release (and to ignore the screams of CI/CD tools ^^).

Thanks for your response, I'll follow up with a feature request ticket and post it here.

On Friday, June 21, 2019 at 3:50:48 PM UTC+2, george wrote:

The answer is indeed to split this into steps.

First step is to allow the field to be nullable if it's not already. Deploy.

Then you create a new deploy (not PR) that stops using the field altogether from all the codebase. You can remove the reference to the field or comment it out. Do not `makemigrations`. Deploy.

Create the last step, which is the migration to drop the field from the database.

On Thu, Jun 20, 2019 at 6:20 PM Matthieu Rudelle <m.ru...@artmyn.com> wrote:

Thank you for the quick answer, although I am not sure what the second step mean and how it actually solves the problem?

The missing column error appears even when no backward migration is called. Both version of the app run side by side, both connected to a single DB migrated with the new code. So when the 3 step is called, the older release will fail.

Best,

Matthieu

On Thursday, June 20, 2019 at 3:07:54 PM UTC+2, Aldian Fazrihady wrote:

My solution to this problem was by adding more migrations steps:

1. Step to make the field nullable. 

2. Backward step to fill value to the removed field. 

3. Step to remove the field. 

Regards, 

Aldian Fazrihady

On Thu, 20 Jun 2019, 19:37 Matthieu Rudelle, <m.ru...@artmyn.com> wrote:

Hi there!

I am about to file a feature request but I figured this might have been discussed (although I can't find where).

The use case is when removing fields in a production environment. We run our django migrations without downtimes, such that basically, from time to time we have an old release working on an DB migrated by the new release.

And when we remove a field it breaks. So we're thinking there should be a way to flag a field as "disabled", its value will not be requested on the DB and default to a hardcoded value. No migration should remove the column yet. Once the field is actually removed the column can be safely removed without breaking the old version.

What do you guys think? Is there a better way to solve this?

Note: a slightly different usecase that it could solve, the third item on this wishlist: https://pankrat.github.io/2015/django-migrations-without-downtimes/#django-wishlist

Best,

Matthieu

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CANP1NSx%3DRu63c2vR4R%3DfbtBEHV3WRqf1XxWtN%3Dd23j3VoA-ZZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/420f1671-2c31-428b-b96b-02f840df2df5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

George R. C. Silva

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/ec538dd2-5497-4500-8079-6b48469af56f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/b19e3625-032c-45c3-a14c-40d5864bf597%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.