UUID as Primary Key (Re. 4682)

[Jonathan Harker <jon@…>]

Re ​Ticket 4682: The OP didn't just want to add a UUID field type, that much should be a reasonably straightforward change. The real idea is to be able to use UUIDs as the primary key, instead of an auto-incrementing integer field. There are cases where this is a much better solution (busy write-heavy databases, remote sync using disconnected or asynchronous datasets, and so on).

I'm interested how much fiddling under the hood this would require, but I imagine a PRIMARY_KEY_TYPE option in settings.py. Since one advantage is there is no need to query the database to get the next integer in the PK field, one can simply generate a UUID code-side. I haven't looked under the hood yet, but presumably somewhere there is code to get the next PK integer when creating a new row, which can be so tweaked to generate a UUID instead, before the insert (and including the PK field and its value in the INSERT statement).

Sorry to ramble but I'd be interested to help out with such a venture :-)

[Jacob]

As I said over in 4682, this is simple to do yourself. Make a UUIDField, then a model with UUIDField(primary_key=True). Marking wontfix again; please take this to django-dev if you feel the need to further discuss this.

[Jonathan Harker <jon@…>]

My apologies - I'm sure you can tell I'm new to Django fresh from reading Chapter 5... I see that I can mark a field in the model as a PK and use auto. This should be sufficient :)

[domguard]

Reopening this ticket, because I'm facing issues (#14724, worst being #12235) because I *really* need UUID primary keys (and worst heretic of all requirements, UUID primary key on the Django User Model!)
My first big django project is based on multi-sites data syncing (implying users and custom models)

I really don't get the "This doesn't have to be included in django" argument.
It's 2010, UUID is a real datatype now, like datetime. It's used for hard-to-guess ID in URL, multi-db syncing issues like mine, etc
The fact that it made its way to postgresql as a possible column type is a sign, no ?

I'm new to Django, so perhaps making a mistake here, but seems to me that, applying the DRY principle to the whole django project and given all the UUIDField implementations found everywhere, all of them having/will have eventually the same problems to face when integrating to django, an official UUIDField for django is needed.
I imagine that this implies lot of cleaning for int-pk specific code everywhere
I picked the django-extensions UUIDField because it seemed it had the better support, but there does not seem to be one implementation without issue right now.

[Carl Meyer]

This ticket is invalid, because it's requesting something that already exists in Django core; the ability to use a UUIDField (or any other type of field) instead of the automatic auto-increment id field as the primary key for a model.

If you are wanting to advocate for inclusion of a UUIDField in Django core (which is what it sounds like), that's #4682, not this ticket. But reopening tickets that have been closed wontfix by core developers is not helpful and against the ​contributing guidelines. Useful things you could do to advocate for this would include starting a conversation on the django-developers mailing list with arguments for inclusion of a UUIDField in core, and working on an external UUIDField implementation to get it into shape that it could be ready for core. (Keep in mind that the absence of an external "implementation without issue" is an argument against, not in favor of, adding UUIDField to core. Making the decision to add something to core does not magically make it work better.)

[erik@…]

Hi carljm,

I think you misunderstood quinode.
The request is to have the possibility to have a UUID as a PK for the standard Django User. This allows you to keep Django's current user model in your application to manage users. Currently this is not possible when you need UUIDs, for example for replication or security reasons.

My own situation is that I need to store users and keeping them as standard Django users is very convenient, because of the many features Django already has for users. However, I also need to implement a custom replication strategy, and using UUIDs is a prerequisite of the way I'm going to replicate my data across different databases.

Currently, it is impossible to replicate the Django users to a different database because they use integer PKs. This would result in me having to re-implement users/authentication and rights from scratch, which is a pain.

So the issue doesn't apply to regular models/tables (This is possible as you mentioned, I currently use UUIDs for all my models), but specifically for Django's internal users.

Hopefully this clarifies the situation somewhat.

[audrius.butkevicius@…]

I believe with Django 1.5 and introduction of custom user models this becomes a more frequent requirement. Even by using standard User or AbstractUser models, users have to possibility to define a custom primary key by modifying the meta class.

Though the documentation specifies that the primary key is supposed to be an integer, the only piece of code (that I can find) enforcing an integer is the password recovery form, which could be modified to accept any form of primary keys.

The benefit of having UUID primary key would mean that you could merge users from multiple instances of the same application without any hassle, or even better, have multiple instances of the same application synchronizing users between them without the fear of PK collision.

[Russell Keith-Magee]

Reclosing, for multiple reasons.

Firstly, this ticket has become hideously confused. Is it about UUID fields? In which case, #4682 (and its supercedent #19463) are existing ticket for this. Is it about Custom users? Then we're talking about #3011 -- which has been fixed at this point. Is it about using non-integer keys for the User model? That's another ticket again -- #14881.

Secondly, this ticket was closed some time ago by a core developer. If you want to reopen discussion about this issue, you should start a thread on django-developers. That said, it's a moot point anyway, because the underlying tickets have all been accepted or already fixed by the core team. What is needed is patches to address these problems.