Code

Opened 7 years ago

Closed 6 years ago

Last modified 29 hours ago

#4682 closed Uncategorized (wontfix)

[patch] Add UuidField

Reported by: John Downey <jtdowney@…> Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords: uuid field
Cc: hv@… Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (2)

UUIDField.py (1.3 KB) - added by anonymous 7 years ago.
UUIDFIeld
uuid.py (19.7 KB) - added by anonymous 7 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 Changed 7 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by 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.

Changed 7 years ago by anonymous

UUIDFIeld

comment:4 follow-up: Changed 7 years ago by anonymous

  • Cc root.lastnode@… added
  • Summary changed from Add UuidField to [patch] Add UuidField

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.

comment:5 Changed 7 years ago by anonymous

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

comment:6 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by 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.

comment:7 in reply to: ↑ 6 Changed 7 years ago by 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.

Changed 7 years ago by anonymous

comment:8 Changed 6 years ago by jacob

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:9 Changed 6 years ago by Jonathan Harker <jon@…>

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

comment:10 Changed 6 years ago by 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.

comment:11 Changed 6 years ago by ubernostrum

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?

comment:12 Changed 6 years ago by trbs

  • Cc root.lastnode@… removed

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

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

comment:13 Changed 2 years ago by guettli

  • Cc hv@… added
  • Easy pickings unset
  • Severity set to Normal
  • Type set to Uncategorized
  • UI/UX unset

comment:14 Changed 23 months ago by 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.

comment:15 Changed 22 months ago by 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!

comment:16 Changed 22 months ago by claudep

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

comment:17 follow-up: Changed 22 months ago by 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.

comment:18 in reply to: ↑ 17 Changed 17 months ago by anonymous

+1

comment:19 Changed 17 months ago by 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".

comment:20 Changed 16 months ago by guettli

I created a new ticket: #19463

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

comment:21 Changed 16 months ago by 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.

comment:22 Changed 3 months ago by Natim87

Any news about that ?

comment:23 Changed 29 hours ago by anonymous

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.