#32577: Add support for `UUIDAutoField` `DEFAULT_AUTO_FIELD`
-------------------------------------+-------------------------------------
Reporter: Tomasz Wójcik | Owner: nobody
Type: New feature | Status: new
Component: Database layer | Version: 3.2
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Samuel Bishop):
Replying to [comment:10 Mariusz Felisiak]:
> Note: Fixing this ticket will also resolve #17337.
This would be an interesting development, and it will be great to make
some progress on the nonrel front.
----
Replying to [comment:11 Nick Pope]:
> - It was named `DEFAULT_AUTO_FIELD` to indicate that it referred to the
''automatically generated'' `id` field.
> - This was instead of `DEFAULT_AUTOFIELD` which would imply that it
could only ever be related to `AutoField`.
> - Another suggestion had been `DEFAULT_MODEL_PK`, but we weren't ready
to allow other fields without `AutoField`-like semantics.
> - We could lift the restriction to allow other non-`AutoField` types,
but the concept of an ''automatically generated'' `id` field needs to be
decoupled from `AutoField` a bit.
While the situation currently doesn't support it, having a
`DEFAULT_MODEL_PK` which accepts any field which sets `primary_key=True`
and `unique=True` would be very very useful as there are lots of use
cases, such as legacy and interoperability scenarios, where having the
primary key generation logic in python is going to be necessary, and its
good to hear that the situation is "were not ready" not "we don't want to
do this".
> - Add a `db_generated`/`is_auto` (or another better name) flag to
`AutoFieldMixin`. (See
[https://code.djangoproject.com/ticket/24042#comment:5 my comment]. I'm
not convinced #24042 should have been closed.)
Reading through that, I agree, it feels like closing the ticket was based
on the smallest possible interpretation of the issue.
> Note that this field would also be limited to databases that have a
function to generate a UUID.
This is another one of reasons why I think `DEFAULT_MODEL_PK` (and thus
lifting the need to have the database generate the primary key value),
should be the ultimate goal, as someone maintaining a ULID Field library
for use as a primary key, even if I go the extra mile and write/maintain
multiple independent database functions/stored procedures (and all the
extra management code to ensure they are loaded, updated, etc) for each
supported database (currently Sqlite, MySQL, MariaDB, PostgreSQL,
CockroachDB, with MSSQL on the horizon), I would "still" like to support
generating the ULID value in python code for the broadest possible
compatibility.
--
Ticket URL: <https://code.djangoproject.com/ticket/32577#comment:12>
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 django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.20f35bbe39c9baa7121f074419a1f857%40djangoproject.com.
