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 > <javascript:>> 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 <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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/15232810-3b58-44d1-a417-0df21f4f712c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
