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

2019-06-29 Thread 'Matthieu Rudelle' via Django users 
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  
>> 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  
 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,  
>> 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

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

2019-06-24 Thread Matthieu Rudelle 
>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  > 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  
>>> 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,  
> 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

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

2019-06-24 Thread Vinicius Assef 
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  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 
>> 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, 
 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-users+unsubscr...@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

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

2019-06-24 Thread Matthieu Rudelle 
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  > 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,  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-users+unsubscr...@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/ec538dd2-5497-4500-8079-6b48469af56f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-06-21 Thread George Silva 
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 
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,  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-users+unsubscr...@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/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-users+unsubscr...@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/CAGyPVTt9BUXWd%3Df-myfD7OVQbwUy8s8ziUa22wM_07P1GK7PZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-06-20 Thread Matthieu Rudelle 
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,  > 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-users+unsubscr...@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/420f1671-2c31-428b-b96b-02f840df2df5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-06-20 Thread Aldian Fazrihady 
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,  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-users+unsubscr...@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/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-users+unsubscr...@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/CAN7EoAYOPbQ-BA8e5Qekyuhr7cc4ueqgz-ihmmC9VdoGkwC0Jg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-06-20 Thread Matthieu Rudelle 
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-users+unsubscr...@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/CANP1NSx%3DRu63c2vR4R%3DfbtBEHV3WRqf1XxWtN%3Dd23j3VoA-ZZw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.