#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 Antonin Grêlé):
Replying to [comment:7 Tomasz Wójcik]:
> What I meant is I think users only use numeric types and uuids for
generic app-wide primary keys so I don't think it's necessary to allow
other types for {{{AutoField}}}, such as string. So instead of refactoring
the entire {{{AutoField}}}, another type - {{{UUIDAutoField}}} could be
added.
Could I argue that IDs based on human-readable strings, like
[https://coolname.readthedocs.io coolname], are a valid use case?
It's easier to reference '"soft-cuddly-shrew-of-expertise" than "a1e1b1c5
-5d5e-4eef-9ee9-e74e87ce71d6" or "2467584".
Would this be seen as bad practice and we should use a slugfield that's
not the primary key for something like this instead?
--
Ticket URL: <https://code.djangoproject.com/ticket/32577#comment:8>
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.7e03fd6f3558317eba706df318d57f73%40djangoproject.com.
