Re: Defaulting to use BigAutoField in models

I have an initial MR for phase 1 here: https://github.com/django/django/pull/13179. It's lacking docs but I think the rest of the points are covered. It still needs docs, but a few observations/thoughts: `UUIDField` is not useful at all without a `default` being set. It's likely not safe to ad

Re: Defaulting to use BigAutoField in models

I spent some time last week experimenting with my patch, the biggest issue I could find was that under some situations we add explicit casts to array fields in Postgres based on the *expected* PK field type (i.e `WHERE [1,2,3]::int @> [1,2,3]::bigint`) which causes the query to be invalid. The

Re: Defaulting to use BigAutoField in models

Email got sent too fast I meant > The warning should warn that the value will default to 'django.db.models.BigAutoField' in a future version of Django. Regarding third party apps a solution could be to allow a per-app config option or encourage them to explicitly choose which primary key they

Re: Defaulting to use BigAutoField in models

+1 from me as well but I don't think we should add any logic to the migration framework to handle the transition. I think the release plan should be something along the following Phase 1: - New projects are generated with MODEL_DEFAULT_PK = 'django.db.models.BigAutoField' - A system check or wa

Re: Defaulting to use BigAutoField in models

This would make the change only affect existing installs of third party apps. I think documentation on using RunSQL() in a migration (in a project app) could be warranted. On Thu, 18 Jun 2020 at 14:50, Caio Ariede wrote: > What about third party apps? > > It would be great to migrate every AutoF

Re: Defaulting to use BigAutoField in models

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

Re: Defaulting to use BigAutoField in models

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

Re: Defaulting to use BigAutoField in models

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

Re: Defaulting to use BigAutoField in models

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

Re: Defaulting to use BigAutoField in models

I think we should re-open ticket 31007[1] as there was a consensus in 2017 during the previous attempt at this[2] and things have not really changed - a 32bit primary key is still not a sensible default given the calamity that can occur when you hit the end of it’s range. The sticky point is t

Re: Defaulting to use BigAutoField in models

I haven't thought this through, but maybe it's possible to restrict the change to inside AutoField, rather than create a new field class. If its db_parameters() method / db_type() could receive enough context from the migration history, it could potentially determine its own database type. For thos

Re: Defaulting to use BigAutoField in models

> I think we should restrict the setting between normal and big auto fields > only. Allowing UUID's would be changing the type, with the potential for > havoc with code incompalities throughout django. It's also not possible to > migrate tables over to the new type. That’s a really good point,

Re: Defaulting to use BigAutoField in models

Big +1 on solving this from me. - The setting would take any dotted path to a class, or a single class name > for a build in field. This would potentially solve [3], and could be useful > to people who want to default to other fields like UUIDs (or a custom > BigAutoField) for whatever reason > I

Re: Defaulting to use BigAutoField in models

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