I just thought I’d take a moment to give everyone a heads up thatMulti-Model Inheritance fixture dumping and loading is now fixed, as per
Russ Magee’s changeset 7600. This fixes a subtle problem that some of
you may have seen in the form of foreign keys pointing to the wrong
objects after using loaddata to restore an app.
The “pk” fields (usually ‘id’) in the serialized dump weren’t being
loaded correctly, meaning that the objects id fields defaulted to the
table’s incremental numbering rather than using the number specified in
your object’s fixture’s “pk” field. This would not be an issue unless
you deleted an object in your original table and thus had a gap in your
primary keys (IE: they were no longer un-interrupted and sequential).
Let’s say you have three objects, 1 (Apple), 2 (Banana), 3 (Orange). You
delete Banana (2) and now have entries with keys of 1 and 3
(non-sequential). Some other arbitrary models point at 1 and 3, and you
now dumpdata your Fruit app and re-load it. The loader ignores the fact
that Orange’s PK is 3 and instead just adds it right behind apple as PK
2 (sequential, the default behavior for primary keys when no value is
specified). All of your other relations pointing at Orange in other
tables are now broken, and you’re likely to see Exceptions thrown or
models pointing to the wrong fruit (if you had more fruit defined to be
compacted into PK 3).
I have a feeling I didn’t explain this well. In the event that you’d
like further elaboration, see the Django-Users post where it’s
outlined a little beter. For those using Multi-Model inheritance and
fixtures, this was a definite show-stopper.
A big thinks goes out to Russ Magee for fixing this!
