#24607: dumpdata (with natural keys) / loaddata failure for model inheriting
from
User
--------------------------------------+------------------------------------
Reporter: denys-duchier | Owner: nobody
Type: Bug | Status: new
Component: Core (Serialization) | Version: 1.8
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by levic):
As it stands right now, `use_natural_primary_keys` doesn't work with
multi-table inheritance with or without `use_natural_foreign_keys` -- the
patch at least allows it to work if both `use_natural_primary_keys` and
`use_natural_foreign_keys` are enabled.
The issue only arises when `use_natural_primary_keys` is set and
`use_natural_foreign_keys` is not. In this case possible options are:
1. `use_natural_primary_keys` implies `use_natural_foreign_keys`
1. Always
1. If there are any multi-table inheritance models defined that have a
natural key
1. Only for references to models that are involved in any multi-table
inheritance
- May be a little surprising if you add an inherited model and it
changes the dump for the parent model changes
1. `use_natural_primary_keys` does not imply `use_natural_foreign_keys`
- dumps may break if load/dump order is not identical as the real PKs may
not match (ie is likely to break)
- If there are any multi-table inheritance models with natural keys then
a warning can be emitted
1. `use_natural_primary_keys` is ignored for models that are involved in
any multi-table inheritance and have a natural_key defined
- May be a little surprising if you add an inherited model and it changes
the dump for the parent model changes
Option 2 involves the least change and with the warning follows the
principle of least surprise. It is an improvement over the current
situation and is as backwards-compatible as possible.
If the patch was bought up to date with the latest django version, and it
was changed to use option 2 (so `use_natural_primary_keys` did not turn on
`use_natural_foreign_keys` but gave a warning if a likely problem was
detected) then would this be acceptable?
--
Ticket URL: <https://code.djangoproject.com/ticket/24607#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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/071.f3efac07f9e4e17d4e86c936d132dbdb%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
