I think we should first discuss if it makes sense to set a BigAutoField by default for all tables. I'm not convinced of that yet. I looked at my projects with this perspective and found for example a case where I have many small lookup tables (containing between 2-20 entries) for which I know I would never use BigAutoField if I'd design the schema on paper.
For me, it's a bit like the `on_delete` parameter for foreign keys. A no "one size fits all" situation. For example, a quick analysis of contrib models (sorry for bad formatting): Model BigAutoField appropriate ======================= admin.LogEntry yes auth.User no auth.Group no auth.Permission no contenttype.ContentType no flatpage.FlatPage no redirect.Redirect no sessions.Session yes sites.Site no Shouldn't we treat that issue by better documentation instead? Another idea is to leverage the system check framework (--deploy part) to warn when the max id is over 50% of available range. We are perfectionists, aren't we :-) Claude -- 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/0fba4c2c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
