Improve migration conflict detection

[Caio Ariede]

Hey folks,

I was looking at the code used to detect conflicts in migrations [1]. It seems 
to use a very safe approach, by avoiding with multiple node leafs in the 
migration graph.

While this is safe, I’ve been having some problems when it comes to scalability 
when having multiple migrations created in a short period of time (for the same 
app).

Questions:

1. Are there any obvious impediments on improving the conflicts detection?
2. Does anyone have ideas on how to improve the conflict detection? (eg. going 
down from app-level to model-level detection)


Thanks!


[1] 
https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313

--
Caio Ariede
caio.ari...@gmail.com




-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com.

Re: Improve migration conflict detection

[Caio Ariede]

I’m working on this as a standalone PoC app for now, I may be able to share a 
repository with the code soon in order to get some feedback

Here’s in simple words where I’m at:

* I’ve replaced the restriction of only-one-leaf-node-per-app from the 
Migration Loader [1] to only-one-leaf-node-per-app-per-model. It means that 
with this, you can have more than one person changing different models in the 
same app, without introducing conflicts. Migrations referring to the same app 
and model would still cause a conflict

* I’m now trying to get the migration graph’s forwards/backwards plan to handle 
cases where there are more than one leaf node in the graph.

I may be doing the wrong assumption here, but it seems to me that migrations 
changing different models shouldn’t introduce a real conflict? If I have the 
following migration graph:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_abc ] => [ 0003_def ] => [ 
0004_auto ]

Where 0003_abc and 0003_def don’t have any model changes in common: no FK 
references, nothing related at all

If this assumption is correct, I could have the two migrations in ANY order in 
the graph, that it would still give me the same result, for example:

[ 0001_initial ] => [ 0002_auto ] => [ 0003_def ] => [ 0003_abc ] => [ 
0004_auto ]


Please let me know if I’m missing something, ideas and thoughts are really 
welcome :)


[1] 
https://github.com/django/django/blob/2a038521c4eabdc5f6d5026d3dd6d22868e329cd/django/db/migrations/loader.py#L301-L313

--
Caio Ariede
caio.ari...@gmail.com




> On Feb 13, 2020, at 11:49, Dave Vernon  wrote:
> 
> If I had to guess, it would be that with more than one leaf node, you would 
> end up a substantial challenge resolving dependancies which would create an 
> Order(N) problem (i.e. there's a chance of excessive time to complete the 
> resolution).
> 
> I certainly worked on some migration logic that took a similar approach to 
> this.
> 
> 
> On Thursday, February 13, 2020 at 2:10:40 PM UTC, Adam Johnson wrote:
> I don’t think many people can answer this off the top of their heads. I 
> certainly can’t and I have contributed a couple things to migrations.
> 
> It’s probably quite necessary there’s only one leaf node but I can’t say for 
> sure.
> 
> On Thu, 13 Feb 2020 at 13:58, caio > wrote:
> Cool. If I'm understanding this correctly, it auto-resolves during 
> makemigrations?
> 
> I'm looking for something that could handle conflicts during the migrate 
> command, but I'm not sure if that's really possible. I guess it depends on 
> how intrinsic the single-leaf-node restriction is to the whole migration 
> system
> 
> Thanks!
> 
> Em terça-feira, 11 de fevereiro de 2020 16:22:16 UTC-3, jackotonye escreveu:
> Definitely a plus one on auto resolving migrations a test package still in 
> planning aims to solve this 
> https://github.com/jackton1/django-migration-resolver-hook 
> <https://github.com/jackton1/django-migration-resolver-hook>
> 
>> On Feb 11, 2020, at 1:42 PM, Caio Ariede > wrote:
>> 
>> Hey folks,
>> 
>> I was looking at the code used to detect conflicts in migrations [1]. It 
>> seems to use a very safe approach, by avoiding with multiple node leafs in 
>> the migration graph.
>> 
>> While this is safe, I’ve been having some problems when it comes to 
>> scalability when having multiple migrations created in a short period of 
>> time (for the same app).
>> 
>> Questions:
>> 
>> 1. Are there any obvious impediments on improving the conflicts detection?
>> 2. Does anyone have ideas on how to improve the conflict detection? (eg. 
>> going down from app-level to model-level detection)
>> 
>> 
>> Thanks!
>> 
>> 
>> [1] 
>> https://github.com/django/django/blob/e3f6e18513224c8ad081e5a19da641f49b0b43da/django/db/migrations/loader.py#L301-L313
>>  
>> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fdjango%2Fdjango%2Fblob%2Fe3f6e18513224c8ad081e5a19da641f49b0b43da%2Fdjango%2Fdb%2Fmigrations%2Floader.py%23L301-L313&sa=D&sntz=1&usg=AFQjCNEx66DSnIBa3UITs1hO7Mwpk_cxgw>
>> 
>> --
>> Caio Ariede
>> caio@gmail.com <>
>> 
>> 
>> 
>> 
>> 
>> -- 
>> 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 view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/FE717E60-7B66-4050-B233-20C47FBF6038%40gmail.com
>>  
>> <https://

Re: [GSoC 2020] Secrets Manager Proposal

[Caio Ariede]

I’m not sure if you did this already, but I would also look at how existing 
third-party libraries are handling this. 

--
Caio




> On Mar 21, 2020, at 02:01, Abhirav Dilip Kariya  wrote:
> 
> Hello everyone,
> 
> I’ve submitted my proposal draft for GSoC for the 'Secrets Manager' idea 
> listed at Django's Wiki for GSoC 2020 
> . 
> 
> Here is the link to my proposal: GSoC Proposal 
> 
> Link to Prototype Gist 
> 
> Link to Prototype 
> 
> Please let me know if you get the time to go through it and have any feedback 
> for me.
> 
> 
> 
> Thanks in advance,
> Abhirav Dilip Kariya
> 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/9c418579-f5c9-402e-8ae9-68b42290224c%40googlegroups.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2D19D91E-0F9D-42DD-A1B5-CBC1FA0508AA%40gmail.com.

Adding ability to choose AutoField type (signed vs unsigned)

[Caio Ariede]

Hi folks,

I’ve been working on ticket #56 "Primary key columns should be UNSIGNED"  
(really old) for a while now. It’s cumbersome and hard to fix for some reasons, 
including backwards compatibility, nothing that a single PR can solve but I’ll 
try to summarize where things are at this moment. Hopefully we can get to a 
consensus so I can continue.

The problem: Django has been storing primary keys as signed integers since the 
beginning and this is considered a waste of resources. Very few people seem to 
use negative values as primary keys, apparently.

The desired solution: We want to change that in a backwards-compatible way to 
not cause migrations to happen in all projects using Django, in all of a 
sudden. This is where things start to get difficult.

These are the links for the related ticket and PR up to this point:

https://code.djangoproject.com/ticket/56 (Primary key columns should be 
UNSIGNED)
https://github.com/django/django/pull/11900 (PR)

—

While I was working on PR 11900, I stumbled across this other PR 8924 
"BigAutoField as new default in 2.0”, and a particular comment from Nick Pope 
got my attention:

https://github.com/django/django/pull/8924#issuecomment-516792989

The idea o adding a new DEFAULT_AUTOFIELD setting made a lot of sense to me, as 
we would be able to keep things backwards compatible.

My first reaction after following that discussion, was to add a missing part 
that would likely help, which was the PositiveBigIntegerField. This is already 
fixed and merged:

https://code.djangoproject.com/ticket/30987

—

Now that we have PositiveBigIntegerField merged in, we can also have 
PositiveBigAutoField and finally move forward with ticket #56. But we’d still 
need the ability to set a different default Auto Field.

To achieve this, I’ve created a new ticket and Mariusz Felisiak suggested to 
bring this discussion to the developers list, whether or not we should move 
forward with this approach:

https://code.djangoproject.com/ticket/31007

I want to hear from you folks, whether or not we can get to a consensus on 
adding this new setting but also, hear any concerns or issues you can 
anticipate.

Ideally, this new setting would default to AutoField until Django 4? After that 
we can make it default to PositiveBigAutoField.

We could (or should) also change the project template to set DEFAULT_AUTOFIELD 
to PositiveBigAutoField for new projecst, as suggested in Nick Pope's comment 
above.


Thank you

--
Caio



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/8E947B86-2228-4DD3-9D6A-C1B6D757652E%40gmail.com.

Re: Adding ability to choose AutoField type (signed vs unsigned)

[Caio Ariede]

I believe that it is already possible to trigger new migrations in a 
third-party app by changing its AppConfig.label, for example. Please correct me 
if I’m wrong.

>From that perspective, it think it wouldn’t be wrong if a migration is created 
>after someone changes its AppConfig’s default_auto_field. The extra migrations 
>could be handled manually using MIGRATION_MODULES.

I feel like adding such option to AppConfig would give a pretty good 
flexibility, but I’m not sure it dismisses the use of 
settings.DEFAULT_AUTO_FIELD. Specially if one desires to keep an old default 
behavior.

--
Caio



> On Apr 10, 2020, at 04:29, Nick Pope  wrote:
> 
> People can also choose to set this for a third-party app by subclassing the 
> AppConfig, but as you say, they'd then be forced to handle migrations 
> manually - is this even avoidable? I'm not sure how this would look for 
> moving to a new default though.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3FE8A93E-1A7F-436D-87CC-3D87A6C16801%40gmail.com.

Re: Remove automatic date-naming of migrations (00XX_auto_YYYMMDD)

[Caio Ariede]

I think making it possible to customize how migration names are generated has a 
great value. Changing something from “auto” to some better/descriptive name has 
its value, but I can also see people creating their own strategies for naming 
migrations.

I work on a project where migration names are fixed to “auto”. We use a similar 
technique to those mentioned in the blog post to do that. The reason is that we 
want to force developers to get conflicts (git) on migration names during the 
review process, rather than having to handle migration merging manually during 
deploy

--
Caio



> On Apr 22, 2020, at 10:05, Adam Johnson  wrote:
> 
> Hi djangonauts,
> 
> In a blog post earlier this year I outlined my technique to prevent Django 
> creating migration files with automatic date names. I had a lot of response 
> with other techniques and ended up adding two more techniques to the post. 
> It's at 
> https://adamj.eu/tech/2020/02/24/how-to-disallow-auto-named-django-migrations/
>  
> 
>  .
> 
> The problem with such migration names:
> 
> When you run Django’s manage.py makemigrations, it will try to generate a 
> name for the migration based upon its contents. For example, if you are 
> adding a single field, it will call the migration 0002_mymodel_myfield.py. 
> However when your migration contains more than one step, it instead uses a 
> simple ‘auto’ name with the current date + time, e.g. 
> 0002_auto_20200113_1837.py. You can provide the -n/--name argument to 
> makemigrations, but developers often forget this.
> 
> Naming things is a known hard problem in programming. Having migrations with 
> these automatic names makes managing them harder: You can’t tell which is 
> which without opening them, and you could still mix them up if they have 
> similar names due to being generated on the same day.
> 
> Django *currently* sets the migration name to something other than the 
> automatic date name in two cases:
> If the migration contains a single operation, it uses a name based on that 
> operation, e.g. 00023_remove_model_field, or 0024_add_model_field (but not 
> for all operation types)
> If the migration consists *only* of model creation operations, it combines 
> their operation names names, which come as just the lower-cased model names 
> e.g. 0025_book_author_sale
> I opened a PR to expand the operation naming for the single case to cover all 
> built-in operations: https://github.com/django/django/pull/12131 
>   
> 
> I'd like to propose using this new full coverage of operation naming to 
> remove the "auto_MMDD" behaviour, and instead always combine operations' 
> "suggested migration names" up until a limit of say 60 characters. I made a 
> commit for that here: 
> https://github.com/adamchainz/django/commit/c2bc6893a05c2c8099e1fb68e688618446641ed6
>  
> 
> 
> This would lead to migration names such as:
> 0026_remove_book_title_add_book_description
> Whilst perhaps long, they're explict and imo easier to work with than the 
> auto_MMDD behaviour.
> 
> Mariusz wrote on the PR:
> 
> Personally, I'm against removing auto named migrations. IMO chaining 
> operation names is even more confusing. 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM10ACO6wEMZXukN6_xy766Bxa8PQOc7teFEQhRmzWxqwA%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/EFFA0FA4-2346-422D-BBCF-9B836F1AB421%40gmail.com.

Re: Defaulting to use BigAutoField in models

[Caio Ariede]

For the record, there was a related discussion a few months ago:

https://groups.google.com/d/msg/django-developers/VFXZpHnuEJc/bbefjX9yCQAJ


> On 11 Jun 2020, at 12:28, Tom Forbes  wrote:
> 
> nsures it will be used meaningfully and not forgotten about until it’s too 
> late.
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/4F05621B-F004-44B5-901E-29962D531804%40gmail.com.

Re: Defaulting to use BigAutoField in models

[Caio Ariede]

> On 17 Jun 2020, at 16:56, Adam Johnson  wrote:
> 
> I think special casing the migrations framework is an avenue to explore, so I 
> created this today and to my surprise it seems to work quite well: 
> https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839 
> .
> 
> That is a pretty neat solution. I think it would work quite well.

I really like that solution as well, it’s pretty fair :)


> 
> What about a way to warn users approaching the limit? I think a database 
> check that detects AutoFields where the next ID is >50% of the way through 
> would be a good solution. That's the kind of monitoring I've built in the 
> past.
> 
> (50% might sound like it's near the limit, but the table is growing with an 
> exponential curve, even quite shallow, it's quite close in terms of time.)
> 

I think this is indeed a good to have.

Would we be able to provide instructions on how to migrate from SIGNED INT to 
UNSIGNED BIG INT? Perhaps a management command that outputs SQL like sqlmigrate?


--
Caio

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/5ECD26CA-339E-4954-A0BA-E7D8296E6988%40gmail.com.

Re: Defaulting to use BigAutoField in models

[Caio Ariede]

What about third party apps?

It would be great to migrate every AutoField to BigAutoField without the need 
to specify them manually.


--
Caio



> On 18 Jun 2020, at 09:40, Adam Johnson  wrote:
> 
> Would we be able to provide instructions on how to migrate from SIGNED INT to 
> UNSIGNED BIG INT? Perhaps a management command that outputs SQL like 
> sqlmigrate?
> 
> It would only be needed to add this to the model:
> id = BigAutoField() 
> 
> Then migrations would pick it up, because the field is no longer auto_created.
> 
> On Thu, 18 Jun 2020 at 13:24, Caio Ariede  <mailto:caio.ari...@gmail.com>> wrote:
> 
>> On 17 Jun 2020, at 16:56, Adam Johnson > <mailto:m...@adamj.eu>> wrote:
>> 
>> I think special casing the migrations framework is an avenue to explore, so 
>> I created this today and to my surprise it seems to work quite well: 
>> https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839
>>  
>> <https://github.com/orf/django/commit/0a335f208cee1376c25eff55c6f866de122c7839>.
>> 
>> That is a pretty neat solution. I think it would work quite well.
> 
> I really like that solution as well, it’s pretty fair :)
> 
> 
>> 
>> What about a way to warn users approaching the limit? I think a database 
>> check that detects AutoFields where the next ID is >50% of the way through 
>> would be a good solution. That's the kind of monitoring I've built in the 
>> past.
>> 
>> (50% might sound like it's near the limit, but the table is growing with an 
>> exponential curve, even quite shallow, it's quite close in terms of time.)
>> 
> 
> I think this is indeed a good to have.
> 
> Would we be able to provide instructions on how to migrate from SIGNED INT to 
> UNSIGNED BIG INT? Perhaps a management command that outputs SQL like 
> sqlmigrate?
> 
> 
> --
> Caio
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/5ECD26CA-339E-4954-A0BA-E7D8296E6988%40gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/5ECD26CA-339E-4954-A0BA-E7D8296E6988%40gmail.com?utm_medium=email&utm_source=footer>.
> 
> 
> -- 
> 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 
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM0W-8ywE%3D3fHpdoMn3%3Dw-3J%2BN2e_nEgJHaNYia-3Xv%2BWw%40mail.gmail.com
>  
> <https://groups.google.com/d/msgid/django-developers/CAMyDDM0W-8ywE%3D3fHpdoMn3%3Dw-3J%2BN2e_nEgJHaNYia-3Xv%2BWw%40mail.gmail.com?utm_medium=email&utm_source=footer>.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/AFE3161D-6571-46B1-AAD3-C21E4A9CE0C0%40gmail.com.

Good example of settings_changed signal usage

[Caio Ariede]

Hello folks,

I want to add a good example of usage for the settings_changed signal to the 
documentation:

https://docs.djangoproject.com/en/dev/ref/signals/#setting-changed

I was looking around the web and it seems there is some confusion around its 
proper use, so I’d like to add a good example that highlights a good and proper 
use case. I’m having a hard time trying to figure out a small and concise 
example.

Ideas? :)

— Caio

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/939ab426-67fd-495c-8a9a-92474189cc6b%40Spark.

Re: Adding ability to choose AutoField type (signed vs unsigned)

[Caio Ariede]

Hello folks,

Now that we’ve completed these:

https://code.djangoproject.com/ticket/31007
https://code.djangoproject.com/ticket/30987

I’m wondering if https://code.djangoproject.com/ticket/56 is still something we 
want to solve.

I feel like the workaround would be to explicitly define ``id = 
models.PositiveBigIntegerField(primary_key=True)``

In the other hand, we could also add ``PositiveBigAutoField`` to make things 
easier now that we have the ability to define the ``default_auto_field`` per 
app.

Thoughts?

— Caio
On 12 Apr 2020 15:01 -0300, Jure Erznožnik , wrote:
> I would like to try again:
> I believe having a general setting for autofields could cause all
> sorts of issues. As illustrated, I immediately thought that some
> people might want to use that for migrating to UUID fields for that (I
> read about using them somewhere about when I started using Django 5
> years ago). The point is that an option like that immediately sparks
> imagination.
>
> However, the problem being attempted at here is only migrating from
> signed to unsigned integer. A very minor change most deployments would
> not even be affected by.
>
> That one could be handled less aggressively by:
>
> > > OTOH, JUST FOR the unsigned vs signed integer PK, it should be relatively 
> > > easy to modify makemigrations code detect existing migrations for the 
> > > model, detect that the only difference is IntegerField vs 
> > > PositiveIntegerField and in this case skip generating the migration (for 
> > > migrating the field to an unsigned one). There could also be a flag to 
> > > the management command specifying to force generating said migrations.
>
> I believe this would be unintrusive enough allowing everyone to
> migrate their models at will. Since most of users won't even notice
> the difference, a solution like this could be preferable even if it
> introduces one additional special case in the code.
> OTOH, the proposed setting DOES provide more flexibility (to introduce
> more varied options for the PK field), but a necessity for a
> biginteger or guid or anything else, for that matter, is already
> catered for in the API - by specifying the super-special pk manually
> for the affected table.
>
> I sure hope I'm not just derailing the discussion with my uninformed
> ideas, but perhaps the minor change could be handled in a simpler
> manner like proposed above.
>
> LP,
> Jure
>
> On Sat, Apr 11, 2020 at 12:21 AM Caio Ariede  wrote:
> >
> > I believe that it is already possible to trigger new migrations in a 
> > third-party app by changing its AppConfig.label, for example. Please 
> > correct me if I’m wrong.
> >
> > From that perspective, it think it wouldn’t be wrong if a migration is 
> > created after someone changes its AppConfig’s default_auto_field. The extra 
> > migrations could be handled manually using MIGRATION_MODULES.
> >
> > I feel like adding such option to AppConfig would give a pretty good 
> > flexibility, but I’m not sure it dismisses the use of 
> > settings.DEFAULT_AUTO_FIELD. Specially if one desires to keep an old 
> > default behavior.
> >
> > --
> > Caio
> >
> >
> >
> > On Apr 10, 2020, at 04:29, Nick Pope  wrote:
> >
> > People can also choose to set this for a third-party app by subclassing the 
> > AppConfig, but as you say, they'd then be forced to handle migrations 
> > manually - is this even avoidable? I'm not sure how this would look for 
> > moving to a new default though.
> >
> >
> > --
> > 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 view this discussion on the web visit 
> > https://groups.google.com/d/msgid/django-developers/3FE8A93E-1A7F-436D-87CC-3D87A6C16801%40gmail.com.
>
> --
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAJ%3D9zicjm4nWYRD9FM0EcMVFbWtj8wPHB084P%2BC_5x9wLgrgPQ%40mail.gmail.com.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7c2f1424-4d48-40eb-832a-d7bbe492d0c5%40Spark.