My suggestion wouldn't be mandatory it would be more like a flag when you are starting a new project. So most people would likely never use it.
Well I think at this point its safe to say that this is not going to happen. On Wednesday, August 31, 2016 at 4:51:54 PM UTC-7, Josh Smeaton wrote: > > A major issue with this would be the many apps out in the wild (and their > tests!) that assume the pk is an integer, and do queries like > .filter(pk=1). I don't like the idea of being able to enforce a different > kind of pk type for apps that you haven't written yourself. > > Is there an actual problem having integer primary keys in standard apps > and django that you're trying to work around? I can understand wanting > uuids for the user model (for very large sites), but there's always the > option of using custom user models for this. Permissions and Groups are > unlikely to need uuids, and building such a system to swap out the actual > type for a new one seems like massive overkill just to keep things > consistent. > > I'd be -0 on such a feature. > > On Wednesday, 31 August 2016 06:43:02 UTC+10, Emett Speer wrote: >> >> My suggestion is more to keep a standard PK for the project rather then >> having 2 PK's. One for the default Django models and one for the rest of >> your project. >> >> With the current setup you would need to override the base User model to >> change the PK from an int to what the rest of the project is using. Where >> if you could set the default PK for the project it would always be of the >> same type unless otherwise declared. >> >> On Tuesday, August 30, 2016 at 1:20:28 PM UTC-7, Ares Ou wrote: >>> >>> You could just explicitly claim the 'id' field in your model, assign a >>> desired type. >>> >>> If you want a model that has the default primary key as UUID for future >>> use, you could write a customized class inherited from models.Model, >>> overriding the 'id' field. >>> >>> I don't feel like this is something needed to be integrated into the >>> official code. >>> >>> See Automation Primary Key Fields: >>> https://docs.djangoproject.com/en/1.10/topics/db/models/#automatic-primary-key-fields >>> >>> >>> Best regards, >>> Ares Ou >>> >>> *Software Engineer / Full-Stack Python Developer | **Phone:* (510) >>> 328 - 5968 >>> >>> *Blog:* http://aresou.net | *Github:* https://github.com/aresowj | >>> *Stack >>> Overflow:* http://stackoverflow.com/users/5183727/ares-ou >>> >>> Ares Ou >>> >>> On Tue, Aug 30, 2016 at 11:43 AM, Tim Graham <timog...@gmail.com> wrote: >>> >>>> Sounds quite complicated. In particular, how could we reasonably test >>>> that contrib apps work with arbitrary PKs? >>>> >>>> On Tuesday, August 30, 2016 at 2:32:18 PM UTC-4, Emett Speer wrote: >>>>> >>>>> Hello Everyone, >>>>> >>>>> I would like to propose the exploration of adding a default PK setting >>>>> do Django. This could be a flag at project creation time or a setting to >>>>> be >>>>> set before the first migration takes place. >>>>> >>>>> This would allow the developer to set the default PK in Django to >>>>> something like UUID. With this things like the default Group, User, etc.. >>>>> models would have UUID based PK's rather then Int based ones and all >>>>> future >>>>> tables would have UUID PK's by default. >>>>> >>>>> Please let me know what you think. >>>>> >>>> -- >>>> 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-develop...@googlegroups.com. >>>> To post to this group, send email to django-d...@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/01763b34-8970-47a4-950e-04343e717514%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-developers/01763b34-8970-47a4-950e-04343e717514%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 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/a2ca32e8-59a8-4425-999c-af7b2b6451d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
