I really like the idea of a global configurable setting. One problem with a setting is that it's not always changeable, which settings kind of imply (IMO). Going from int->bigint is always possible, but going backwards may not be, nor might going from int->guid.
I attempted an int->guid migration on one of our systems and ran into some migrations and postgres-specific issues. Seems like it might be incredibly difficult to get a simple toggle setting to work with it, and there are lots of pitfalls. A warning to the system check framework could be added to check if the primary key type is changed and potentially incompatible generic foreign key columns exist. And in the docs rather than use a plain IntegerField, just use a field that changes based on the setting. On 10 Jun 2017 10:41, "Curtis Maloney" <[email protected]> wrote: f) let MySQL users opt for PositiveBigAutoField if they want... On 10/06/17 19:40, Curtis Maloney wrote: > Right, hence my point of having a global setting to say "the default > auto-field is ..." > > This would: > a) let people continue to use AutoField > b) let people opt for BigAutoField > c) let 3rd party projects be agnostic > d) let people use UUIDField(default=uuid.uuid4) > e) possibly make it feasible to change mid-stream from AutoField to > BigAutoField... > > -- > C > > On 10/06/17 19:33, Claude Paroz wrote: > >> 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 [email protected] >> <mailto:[email protected]>. >> To post to this group, send email to [email protected] >> <mailto:[email protected]>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/0fba4c2 >> c-cd56-4c7d-82b9-7be0a7a3d233%40googlegroups.com?utm_medium= >> email&utm_source=footer>. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/ms gid/django-developers/ec59bb2e-bce9-924f-1509-60709a07c5dc%40tinbrain.net. For more options, visit https://groups.google.com/d/optout. -- 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 [email protected]. To post to this group, send email to [email protected]. 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/CAFNZOJMntP93kaJ%2BbPuHzAr2rKqZbbSbu1TRc%2Bm%2Bp-%2BiO%2BojvQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
