Code

Opened 19 months ago

Last modified 3 months ago

#19463 assigned New feature

Add UUID Field to core

Reported by: guettli Owned by: mjtamlyn
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: trbs@…, matt@…, mike@…, glic3rinu, cyphase@…, jonathan+django@…, tomek@…, saxix.rome@…, loic@…, galuszkak@…, ashwoods Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

on django-dev Dec 2012

If someone can come up with a good patch I'd be fine considering it for core.

Jacob (Kaplan-Moss)

Related: #4682 was closed five years ago.

I (Thomas Güttler) want to moderate this ticket, but won't create patch.

Attachments (0)

Change History (16)

comment:1 Changed 19 months ago by trbs

  • Cc trbs@… added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 19 months ago by claudep

Note that in databases other than PostgreSQL, it might be desirable to store internally the UUID value as binary, not as a char, both for performance reasons and for compatibility with Postgres' uuid (stored as a 128 bits binary). So we might need to solve #2417 beforehand...

comment:3 Changed 19 months ago by schinckel

  • Cc matt@… added

One thing I found with my UUIDField is that I needed to supply code to enable South to (a) handle this field type on migrations, and (b) prevent it trying to create a default at the time a migration is run.

Specifically, https://bitbucket.org/schinckel/django-uuidfield/commits/69f7c0cdf91d28da2cceaff6f46ece34f733b560 shows how to do this.

I would assume we wouldn't want to have any code related to providing data to south in django core, so perhaps we would need to ensure that South releases a version around the same time as after this patch is included.

comment:4 Changed 19 months ago by carbonXT

  • Cc mike@… added

comment:5 Changed 19 months ago by akaariai

I've been thinking that we would likely want to have a new field type: GeneratedField. This is like AutoField - the field gets a value on save() if it doesn't already have a value, and this field type is always a primary key (I am not 100% sure of the PK requirement, but it could simplify things). GeneratedField would have a backing field (the db storage type) and some generator, where the generator could fetch the value from DB using RETURNING, could generate the value in Python (like default, but with access to connection), or it could fetch the value after save from the DB (AutoField does this using select currval(someseq) on some backends).

I think such a field type would cover a lot of requests we have currently - unsigned serial fields, tiny/big/...integer serial fields, UUID fields (no matter what the UUID generator function is), and likely some more.

I don't know how hard such a field will be to write, or what the exact API should be - so this is mostly hand waving at the moment. Still, it seems there are only two public API places where this would affect current code - model.save() and bulk_create(), so it seems this should not be totally out of reach as a feature.

comment:6 Changed 19 months ago by akaariai

  • Triage Stage changed from Unreviewed to Accepted

Quoting Jacob from the recent django-developers discussion: "If someone can come up with a good patch I'd be fine considering it for core.".

So, marking as accepted based on that.

comment:7 Changed 19 months ago by glic3rinu

  • Cc glic3rinu added

comment:8 Changed 19 months ago by cyphase

  • Cc cyphase@… added

comment:9 Changed 17 months ago by jonathan

  • Cc jonathan+django@… added

comment:10 Changed 13 months ago by oinopion

  • Cc tomek@… added

comment:11 Changed 12 months ago by saxix

  • Cc saxix.rome@… added

comment:12 Changed 12 months ago by loic84

  • Cc loic@… added

Big +1 on @akaariai's GeneratedField idea.

For example I use extensively what I call a "readable unique ID", similar to YouTube video IDs (i.e. "sc5vraPpTcA"), for which I made a custom Field. It functions like a UUID but trades the creation convenience (guaranteed uniqueness) for usage convenience (being able to read it out loud, shorter URL, etc.). A GeneratedField would allow me to implement that cleanly.

That said, some databases have native support for UUIDs and it's pretty much the standard for sharding, so we could have the generic GeneratedField and a UUIDField subclass.

I'd work on a patch with some guidance from @akaariai.

Last edited 12 months ago by loic84 (previous) (diff)

comment:13 Changed 8 months ago by galuszkak

  • Cc galuszkak@… added
  • Version changed from 1.4 to master

comment:14 Changed 5 months ago by ashwoods

  • Cc ashwoods added

comment:15 Changed 5 months ago by mjtamlyn

  • Owner changed from nobody to mjtamlyn
  • Status changed from new to assigned

For postgres at least, this will form part of my upcoming work on django.contrib.postgres. Support for bigserial is also likely to come in with that, so a more general base class for AutoField might be useful. That said, a UUIDField does not always want to be autogenerated (unlike an autoincrementing which probably should be) - it is a reasonable use case for an API client to generate a uuid (using the uuid4 approach which has a very high probability of avoiding clashes) and expect that to be saved by a Django backed API.

Supporting a simple UUIDField(default=uuid.uuid4) should be a good start.

comment:16 Changed 3 months ago by japrogramer@…

I have written a UUID Field for django that supports 1.7 and its features, migrations serialization etc.
The field can be set with a UUID instance, either a hyphenated str or one that is not. also it can be created with bytes if that is needed. It can auto generate the uuid aka uuid4 and supports the other variants that python's uuid module offers (1,3,4,5). Queries work with either str or UUID instances but not with bytes because who is ever going to query by the bytes, em I right? https://github.com/japrogramer/django-uuid-contour
P.S.
Many tests are included and supports python 3.4 ;)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as assigned
The owner will be changed from mjtamlyn to anonymous. Next status will be 'assigned'
The ticket will be disowned. Next status will be 'new'
as The resolution will be set. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.