Re: [Feature Request][Model, ORM] Disabling a field before removal to support continuous delivery

['Matthieu Rudelle' via Django developers (Contributions to Django itself)]

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 
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 s

Difficulty setting dynamic 'db_table' in Meta

[Brock Hallenbeck]

I am trying to modify django's default table naming scheme to better suit 
my needs and am having some difficulty.

In order to accomplish this I need access to the 'app_label' and 
'model_name' attributes. However due to python's scoping, I am unable to do 
so in your standard Meta subclass.

I have successfully implemented a custom metaclass, that overrides __new__ 
in order to set the 'db_table' attribtue to what I want, however upon 
running makemigrations, this custom behavior is seemingly ignored.

This stack overflow question illustrates the problem. 


Is there some magic that I am not aware of going on inside makemigrations?

-- 
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/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Difficulty setting dynamic 'db_table' in Meta

[Adam Johnson]

Hi,

The SO post shows you (?) testing on Django 1.10, have you tried with the
latest 2.2?

You could also try implementing this with just a class decorator which is
much more likely to work, although it’s not inheritable.

You could also enforce with a a custom system check for manual declaration
of db_table. It could iterate over the models in your project’s apps and
return one check Error for each model with a db_table that doesn’t match
the desired naming scheme.

Thanks,

Adam

On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck 
wrote:

> I am trying to modify django's default table naming scheme to better suit
> my needs and am having some difficulty.
>
> In order to accomplish this I need access to the 'app_label' and
> 'model_name' attributes. However due to python's scoping, I am unable to do
> so in your standard Meta subclass.
>
> I have successfully implemented a custom metaclass, that overrides __new__
> in order to set the 'db_table' attribtue to what I want, however upon
> running makemigrations, this custom behavior is seemingly ignored.
>
> This stack overflow question illustrates the problem.
> 
>
> Is there some magic that I am not aware of going on inside makemigrations?
>
> --
> 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/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Adam

-- 
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/CAMyDDM2p9y9xEmZ2iAAfwDfLowmOqVcFnZf5cX8oBcTkvQqS3A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Difficulty setting dynamic 'db_table' in Meta

[Brock Hallenbeck]

Sorry for the confusion. That post is not actually me, just an identical 
situation. I am in fact on 2.2. It's just frustrating because I can raise 
an arbitrary exception in my metaclass and makemigrations will fail because 
of it, so I know the code is being run. It just seems to be inexplicably 
ignored. 

I will look into the decorator, although I am sad i'll be losing 
inheritance.

On Wednesday, June 26, 2019 at 12:01:31 PM UTC-4, Adam Johnson wrote:
>
> Hi,
>
> The SO post shows you (?) testing on Django 1.10, have you tried with the 
> latest 2.2?
>
> You could also try implementing this with just a class decorator which is 
> much more likely to work, although it’s not inheritable. 
>
> You could also enforce with a a custom system check for manual declaration 
> of db_table. It could iterate over the models in your project’s apps and 
> return one check Error for each model with a db_table that doesn’t match 
> the desired naming scheme.
>
> Thanks,
>
> Adam
>
> On Wed, 26 Jun 2019 at 15:50, Brock Hallenbeck  > wrote:
>
>> I am trying to modify django's default table naming scheme to better suit 
>> my needs and am having some difficulty.
>>
>> In order to accomplish this I need access to the 'app_label' and 
>> 'model_name' attributes. However due to python's scoping, I am unable to do 
>> so in your standard Meta subclass.
>>
>> I have successfully implemented a custom metaclass, that overrides 
>> __new__ in order to set the 'db_table' attribtue to what I want, however 
>> upon running makemigrations, this custom behavior is seemingly ignored.
>>
>> This stack overflow question illustrates the problem. 
>> 
>>
>> Is there some magic that I am not aware of going on inside makemigrations?
>>
>> -- 
>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@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/4319b82c-e5b7-49c4-811c-23d42ca612c6%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Adam
>

-- 
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/e0061fa8-8f09-4ba2-ba67-34b55b0e7d74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.