#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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/067.7e03fd6f3558317eba706df318d57f73%40djangoproject.com.
