#36075: Field.primary_key documentation should details its interaction with
CompositePrimaryKey
-------------------------------------+-------------------------------------
Reporter: Simon Charette | Owner: Simon
Type: | Charette
Cleanup/optimization | Status: assigned
Component: Documentation | Version: dev
Severity: Release blocker | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by Simon Charette):
* owner: (none) => Simon Charette
* status: new => assigned
Comment:
Sleeping on it I think it's fine that we keep things as they are code wise
on the assignment of `primary_key = False` when used with
`CompositePrimaryKey` as long as we clearly document that
`_meta.pk_fields` should be used. The reason is that many of the
`field.primary_key` usages immediately stop when they first their first
match so they are likely broken anyway.
Forcing third-party applications that wish to support composite primary
keys to migrate to `_meta.pk_fields` and abandon `.primary_key` seem like
a better option that having code implicitly break because they only expect
one field to have `primary_key = True` which is decade old assumption.
--
Ticket URL: <https://code.djangoproject.com/ticket/36075#comment:6>
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/010701944be3c132-e8745018-73bb-4dcd-861d-18939ca3b1a3-000000%40eu-central-1.amazonses.com.
