[patch] Add UuidField

[John Downey <jtdowney@…>]

I am suggesting a new field type in django.db.models for storing UUID's. This can currently be done with a CharField but what I would like to see is for it to be an auto field that can be used as a PK. I have started looking at the code to produce a patch but before I put to much effort into it I wanted to submit a ticket to see what others thought of this idea.

[Malcolm Tredinnick]

I'm probably -1 on including this into core, since it's not something everybody is going to need. We can't include every field that people might want, since it would lead to dozens of internal field classes. Fortunately ,we're about to make it easier to create new Field sub-classes, so this is something that will benefit from that work and you can use it without needing to modify core.

I won't close this immediately, in case somebody comes up with a really strong counter-argument, but barring that, we should close this in a few days.

[anonymous]

I'm a Django newbite, but UUID support is one of the first things I looked for in the midst of reading the tutorials.

[Karol_joc]

I agree that UUID should be a basic model field. I know you can't include all the fields people require but if Django states that it supports MYSQL then it should at least carry all availble field types for MYSQL.

[anonymous]

UUIDFIeld

[anonymous]

i needed an uuid field for my django project and i wrote this custom Field.
it uses the new uuid.py module from python 2.5

you can copy the uuid.py file from the current python2.5 distribution and place it somewhere in the python path
i found that django.utils looked like a good place for it.

[anonymous]

p.s. sorry i see that the patch has some indentation errors on line: 21 and 23

[James Bennett]

Replying to anonymous:

i needed an uuid field for my django project and i wrote this custom Field.
it uses the new uuid.py module from python 2.5

Django has a stated policy of maintaining compatibility back to Python 2.3, so if it's possible to do this without having to bundle a Python 2.5 module that would be vastly preferable.

[anonymous]

Replying to ubernostrum:

Replying to anonymous:

i needed an uuid field for my django project and i wrote this custom Field.
it uses the new uuid.py module from python 2.5

Django has a stated policy of maintaining compatibility back to Python 2.3, so if it's possible to do this without having to bundle a Python 2.5 module that would be vastly preferable.

Sorry last my eye on this ticket... The patch uses Python 2.5's uuid module if available otherwise is looks for the uuid.py module in django.utils.
(somewhere i hope django officially takes this up into it's distribution :) )

In the mean time people using python 2.3 or 2.4 (like i am, my mod_python py version is 2.4) can copy the file from the standaard Python 2.5 distribution.
The py2.5 uuid.py is not 2.5 specific it's only included for the first time in py2.5.

For clarity i also attached uuid.py to this ticket. Copy uuid.py to /path/to/django-trunk/django/utils or where ever your django framework is located and it should work.

[Jacob]

Since it's now pretty easy to make your own fields, adding this to Django core isn't needed.

[Jonathan Harker <jon@…>]

Resurrected as ​Ticket 6663 to discuss UUID as a PK instead of auto-incrementing integer.

[anonymous]

Isn't saying "Since it's now pretty easy to make your own fields, adding this to Django core isn't needed" a violation of DRY? Why should thousands of Django users duplicate something that is a pretty standard function in modern development environments? Even Postgres 8.3 now has native support for UUID datatype, storing as a 128 bit integer, instead of a silly 32 byte string.

[James Bennett]

Isn't saying "Since it's now pretty easy to make your own fields, adding this to Django core isn't needed" a violation of DRY?

Did someone magically take away the ability of people to share code that's not in Django core, and I missed it?

[trbs]

for future reference, this field is now part of django-extensions.

​http://code.google.com/p/django-command-extensions

[ragi@…]

If it were in core, then Django could leverage the 128bit field in PostgreSQL which would speed up most queries that rely on this field. Please note that people that use uuid as a field, it is most likely because they are using it as a key in their queries. Please consider re-opening.

[anonymous]

I vote++ on this.

In 2012 it is definitely worth considering adding UUID as a field type in the core Django codebase. Many of the Django DB backends now support UUID as a real type (read: 1st rate, optimized, indexed >> the PG 128bit field is a backend implementation example).

I know it is easy to implement or pull in from django_extensions but, seriously, UUIDs are not just CharFields in some of these backends. Isn't it time that django seriously considers growing up with the DBMS that it supports?

Thanks!

[Claude Paroz]

If you want that the won't fix decision to be reevaluated, please discuss it first on the django-developers mailing list.

[anonymous]

New Django user here. Considering all of the features I've read about in Django, I was thoroughly surprised & disappointed to find UUIDs are not part of its core.

The ease of adding a custom field is beside the point. UUIDs have their place and I fail to see a valid reason we should have to jump through hoops to use such a common field.

[anonymous]

+1

[anonymous]

Old Django user here :-)

To my knowledge, there is no 3rd party implementation that uses native SDBG UUID types. Current implementations subclass Charfield, because it's the easy thing to do, but it's slow.

First, given the way we ./manage.py dumpdata to JSON, it causes many problems with AUTO INT as primary keys when loading back data. Using a UUID solves this.

Secondly, having no standard way to use UUID as primary key for stuff like auth.User, perms and groups is really a bummer (ever try to share test data with perms with your fellow coworkers ?), and is a direct consequence of the fact that UUID are not part of the Django core: nobody ever think about them. Some thing goes with URLs: we got slugs and ids for URL, but we won't include a UUID in it (it's ugly). Nobody will try to think of an elegant solution to that before it becomes so natural to have UUID that you are forced to wonder. Beginers don't even know UUID are an options, it's a real shame.

Thirdly, UUID are now core part of big websites since they are more or less required for serious database replication, sharding, and sharing a common reference accross different databases (especially NoSQL).

It's really becoming a requirement, not an option. Not having it in the core 3 years ago would have make sense, but in 2012 you do expect this from a Web framework. I've seen more people using UUID than python 3 or asynchronous requests handling, and the two are now on the TODO list while being much more costly to develop.

I know you have limited ressources and want to limit the number of things in the framework. No hard feelings there. It's just it's worth considering it again: the Web is a different place now than 5 years ago, when it was set to "won't fix".

[Thomas Güttler]

I created a new ticket: #19463

Jacob has announced that UUID field could be added to core.

[iamio@…]

Glad to hear that UUID is hopefully coming to the core.

I just came across this problem developing an online store. Purchase orders are referenced by the AUTO INT field, but then this exposes a lot of information to end users. A malicious end user will know every primary key in my table, and business competitors can discover how many transactions that the store processes online. Even if it is easy for a user to create a UUID field, AUTO INT fields are less secure than UUID's, so Django should be discouraging the use of AUTO INT for any primary key that is visible to end users.

[Natim87]

Any news about that ?

[anonymous]

I have written a UUID Field tha supports django 1.7 and python 3.4
​https://github.com/japrogramer/django-uuid-contour