#32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`
-------------------------------------+-------------------------------------
Reporter: Tomasz Wójcik | Owner: Tomasz
| Wójcik
Type: New feature | Status: assigned
Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: uuid | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* cc: Simon Charette (added)
Comment:
Maybe a naive question but what purpose does a Postgres specific
`UUID4Field` provides now that we generically support defining a primary
key field with a `db_default` and have it returned by the database using
`RETURNING` on all backends that support it?
{{{#!python
class Foo(models.Model):
id = models.UUIDField(primary_key=True, db_default=RandomUUID())
}}}
and why chose UUIDv4 specifically now that UUIDv7 is most likely a better
candidate?
This ticket was created before generic support for db-generated defaults
landed in core and when ULID / UUIDv7 were not as omnipresent as they are
today and which made this feature request age poorly.
Wouldn't a better solution be to have a `DEFAULT_PK_FIELD` setting (that
supplants `DEFAULT_AUTO_FIELD`) that accepts any `db_returning` field
instead of trying to create an overly specialized Postgres specific
solution that happens to break third-party expectations with regards to
what exactly constitutes an auto-field?
From looking back at #31007 it seems that having a setting that was not
tailored to `AutoFieldMixin` subclasses was agreed upon
[https://groups.google.com/g/django-
developers/c/MBPEPKlibGQ/m/F4i6JPvBAAAJ on the mailing list] and well as
[https://github.com/django/django/pull/13179#discussion_r461779004 during
the first phase of the implementation] but we
[https://github.com/django/django/pull/13179#discussion_r463988623 then
took a different route].
Looking back at the current state of things now I think would be much more
value in allowing any fields to be used for a `DEFAULT_PK_FIELD`,
deprecate `DEFAULT_AUTO_FIELD`, and provide a database agnostic
`RandomUUID` database function that can be used on SQLite, Postgres,
MySQL, and Oracle so the requested feature here can be implemented as
{{{#!python
# core/fields.py
class UUIDPrimaryKeyField(models.UUIDField):
def __init__(self, *args, **kwargs):
kwargs["primary_key"] = True
kwargs.setdefault("db_default", RandomUUID())
# settings.py
DEFAULT_PK_FIELD = "core.fields.UUIDPrimaryKeyField"
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32577#comment:37>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/010701961243144a-cddd4101-fc78-4fd7-9226-7e0f235cab29-000000%40eu-central-1.amazonses.com.
