Changing DEFAULT_AUTO_FIELD to BigAutoField

Django Internals
1

In Django 3.2, the DEFAULT_AUTO_FIELD setting and AppConfig.default_auto_field attribute were added to start nudging users from AutoField to BigAutoField.

The default startproject template has DEFAULT_AUTO_FIELD = ‘django.db.models.BigAutoField’ and the default startapp template has default_auto_field = ‘django.db.models.BigAutoField’ but django.conf.global_settings has DEFAULT_AUTO_FIELD = “django.db.models.AutoField”.

I’d like to propose completing phase two of the plan: changing the DEFAULT_AUTO_FIELD in django.conf.global_settings to BigAutoField. Since there has has effectively been a quasi-deprecation warning generated by the system check framework since Django 3.2 if neither DEFAULT_AUTO_FIELD nor AppConfig.default_auto_field are set, I think no deprecation period is needed and we can make these changes in Django 6.0:

  1. Change django.conf.global_settings.DEFAULT_AUTO_FIELD from “AutoField” to “BigAutoField”
  2. Remove DEFAULT_AUTO_FIELD = ‘django.db.models.BigAutoField’ from the default project template.
  3. Remove default_auto_field = ‘django.db.models.BigAutoField’ from the default app template.
  4. Remove the system check that’s acted as a deprecation warning (example output below):

WARNINGS:
app_label.Model: (models.W042) Auto-created primary key used when not defining a primary key type, by default 'django.db.models.AutoField'.
HINT: Configure the DEFAULT_AUTO_FIELD setting or the AppConfig.default_auto_field attribute to point to a subclass of AutoField, e.g. 'django.db.models.BigAutoField'.

5 Likes
2

Big +1 from me. It’s time.

After all the places I’ve been, seeing the efforts required over years to monitor and migrate huge, high-traffic tables to bigint… It’s time we ensured that the pain fully stops for future engineers.

3

Thanks for raising this Tim, yes, good idea. We have to do it at some point, and I guess a .0 is a good moment.

@nessita/@sarahboyce, and indeed @jacobtylerwalls :partying_face: — My only reservation would be dropping this on you close to the feature freeze, when quite likely you’ve got a backlog to address for that already. How’s that looking?

1 Like
4

I hope I’ve offered a high-quality patch that shouldn’t take more than a few minutes to review.

5

I expect nothing less Tim :wink: My query still remains.

6

I am also +1 on the technical side, but I share (and thank) Carlton’s concern about timing. Feature Freeze is Sept 17, which is already tight. To make it more challenging:

  • Our top priority is Jacob starting on Aug 25 :partying_face:, so we will have onboarding to do which takes time.
  • Our second priority is a security release (to be announced next week) happening Sept 3, and we hope to pair with Jacob on that for training, so the release will be inherently more involved.
  • Sarah will be semi-available the first two weeks of September due to travel.
  • DjangoCon US is Sept 8-12, and I will be attending and out Sept 5-12. I believe Jacob may also be attending, which is amazing, but it means less/no review capacity.
  • We already have a committed backlog of new features to shepherd, including CSP decorators, Django tasks, and, less “featury” but equally relevant, a new shiny docs extra linter.
  • And then there are the requests we got months ago in the 6.0 dedicated forum post.

All of that plays against the odds of us taking this comfortably before freeze. So, if the patch is really as small and self-contained as Tim says, we can aim for it, but expectations should be realistic. Otherwise, it might be better to land early in the 6.1 cycle rather than rush it now.

As 6.0 release manager I will do my best here and keep folks posted. In the meantime, if anyone would like to help with pending 6.0 items, the tickets raised by David and Adam in the post linked above could use some reviews, and that would certainly help.

Lastly, no PR really takes just a few minutes to review. Maybe typo fixes come close, but even those can take longer once you account for docs building and manual checks. A change like this will require hours, if not days, to include proper manual testing and docs adjustments. It would be great if the time needed for review work was not minimized. I don’t feel comfortable landing changes that I haven’t perused consciously.

7

Of course, I don’t mean to be rude or pushy. I completely understand what it’s like to feel like people are dumping requests on you at the last minute. What I meant is that when I was a fellow and authored a patch like this, I don’t think anyone spent hours or days reviewing it. It’s possible my abilities have greatly diminished, and I’m no longer to be trusted with such cursory reviews. :wink: Indeed, skepticism may be warranted considering a reviewer pointed out today that my supposedly “high-quality” patch failed at the most basic task of changing the value in django.conf.global_settings, which was kind of the main point. :grimacing: :rofl: (I have now addressed this deficiency.)

2 Likes