I’d like to re-propose switching Django to use BigAutoField’s rather than the current AutoField. This has been proposed[1] before (and a MR made[2]) but it was closed due to implementation issues and not much else has happened since then.
As many of you are aware the max value a standard AutoField can hold is 2,147,483,647 (2.1 billion) which sounds like more than you can ever need. But it’s often not, and you only find out at the worst possible time - out of the blue at night and during a period of rapid growth. The process for fixing this issue also becomes a lot harder as your data grows - when you’ve hit the limit you’re looking at a multi-hour `ALTER TABLE` on Postgres during which writes and reads are blocked, or a risky operation to create a new table with the correct primary key and copy old data over in batches. Basically if you’ve experienced this before you wouldn’t wish it on your worst enemy. I’m proposing that we add a `MODELS_PRIMARY_KEY` (name improvements welcome!) setting that _defaults_ to `BigAutoField`, with prominent docs/release notes saying that to preserve the existing behaviour this should be set to `AutoField`. I think this the only realistic way we can implement this for new projects in a way that ensures it will be used meaningfully and not forgotten about until it’s too late. Rails managed to do this migration somewhat painlessly due the big differences between Rails and Django models. As Django migrations are derived from the current model state so there’s no way I can think of to express “make this auto-generated field a BigAutoField only if this model is new”. The way I see it is that a global setting is very easy to toggle and there is little chance of missing the large numbers of migrations that would be generated during the Django update. Smaller applications could apply the migrations with little issue and larger applications would be able to opt-out (as well as be reminded that this is a problem they could face!). Some specifics: - 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 - The setting would also be used for GenericForeignKeys, which right now are backed by a PositiveIntegerField and so suffer from the same AutoField limitations Any thoughts on this? Tom 1. https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ <https://groups.google.com/d/msg/django-developers/imBJwRrtJkk/P4g0Y87lAgAJ> 2. https://github.com/django/django/pull/8924/ <https://github.com/django/django/pull/8924/> 3. https://code.djangoproject.com/ticket/56 <https://groups.google.com/d/msg/django-developers/VFXZpHnuEJc/bbefjX9yCQAJ> -- 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/435EC704-3EF6-4EF4-BF85-175AE29C01F5%40tomforb.es.
