#32577: Don't enforce `DEFAULT_AUTO_FIELD` to subclass from `AutoField`
-------------------------------------+-------------------------------------
Reporter: Tomasz | Owner: nobody
Wójcik |
Type: | Status: new
Uncategorized |
Component: Database | Version: 3.2
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Default auto field introduced in #31007,
[https://docs.djangoproject.com/en/3.2/releases/3.2/#customizing-type-of-
auto-created-primary-keys as seen in the docs], is `BigAutoField`.
{{{
class BigAutoField(AutoFieldMixin, BigIntegerField):
def get_internal_type(self):
return 'BigAutoField'
def rel_db_type(self, connection):
return BigIntegerField().db_type(connection=connection)
}}}
Many projects prefer UUID field over big int for pk. So far we had to use
a mixin for that but I am under the impression `DEFAULT_AUTO_FIELD` exists
to lift this burden.
I'd expect something like this to work (additional adjustments might be
needed)
{{{
from django.db import models
from django.db.models.fields import AutoFieldMixin
class UUIDAutoField(AutoFieldMixin, models.UUIDField):
def get_internal_type(self):
return 'UUIDAutoField'
def rel_db_type(self, connection):
return models.UUIDField().db_type(connection=connection)
}}}
But if I use this for `DEFAULT_AUTO_FIELD` I get the error
{{{
ValueError: Primary key 'common.fields.UUIDAutoField' referred by
DEFAULT_AUTO_FIELD must subclass AutoField.
}}}
I noticed two things I want to share.
First, the default auto field `BigAutoField` is not subclassing
`AutoField` so it's not consistent with the error message.
Second, `AutoField` is subclassing `IntegerField`. If I understand this
correctly, users are limited to subclass `IntegerField` for
`DEFAULT_AUTO_FIELD`. If so, there's no way to implement `UUIDAutoField`
as `DEFAULT_AUTO_FIELD`.
I understand auto fields need to share a common interface but having to
subclass `IntegerField` is a big constraint.
I'm happy to open a PR once I know what's the desired functionality.
Possible solutions I see:
- enforce subclassing from `AutoFieldMixin` instead of `AutoField`
- I don't think this field has to be very generic because DB pk types are
very limited. As far as I know, only ints and UUIDs make sense for pk.
Maybe adding `UUIDAutoField` to django fields would make sense. That way
it'd have to enforce subclass of `AutoField` or `UUIDAutoField`
Mentioned also in [https://groups.google.com/g/django-
developers/c/MBPEPKlibGQ/m/uJVZbMpqBAAJ here],
[https://groups.google.com/g/django-
developers/c/MBPEPKlibGQ/m/ntEoLCCMBAAJ here] and
[https://github.com/django/django/pull/13179#issuecomment-742473840 here].
{{{
Django==3.2rc1
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32577>
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 on the web visit
https://groups.google.com/d/msgid/django-updates/052.bced84691e647998b4f5ff1601536553%40djangoproject.com.
