Django

Code

Ticket #7350 (closed: fixed)

Opened 3 months ago

Last modified 3 months ago

Multi-table Models and Fixtures

Reported by: gtaylor Assigned to: nobody
Milestone: Component: Core framework
Version: SVN Keywords: model, inheritance, subclass, fixture
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

It seems like multi-table sub-classed models (not abstract) don't honor the "pk" being specified in fixtures. For example, I have an Event class that is sub-classed by a Race model. The Event class is in an app called "calendar" and the Race model is in an app called "regattas". I dumpdata regattas, reset both apps, and loaddata the regattas fixture. It loads properly but all of the PKs are now sequential, meaning a lot of other models are now pointing at the wrong regatta primary keys. There were regattas with PK IDs 14, 16, and 18, but are now 1, 2, and 3. I have confirmed that the fixture contains the old 14, 16, and 18 primary keys.

The problem is the keys seem to be compacted rather than being loaded from the fixture. The keys are not always uninterrupted sequences of numbers due to deletes. So the problem doesn't exhibit itself until you delete, dumpdata, then try to re-load.

Attachments

Change History

06/08/08 11:39:11 changed by gtaylor

  • needs_better_patch changed.
  • needs_tests changed.
  • needs_docs changed.

It looks as if this might be a problem in django.core.serializers. I tried to thumb through it but have absolutely no idea where to start.

06/09/08 09:03:35 changed by russellm

  • status changed from new to closed.
  • resolution set to fixed.

(In [7600]) Fixed #7350, #7202 -- Fixed serialization for multi-model inheritance, which had multiple problems:

  • Serializers were including all superclass fields in their output. Now only local fields are included.
  • Implicit OneToOne? primary keys were not correctly added to the metamodel, so they were always marked to be serialized, even though they were primary
  • Model saving was too aggressive about creating new parent class instances during deserialization. Raw save on a model now skips saving of the parent class.

Add/Change #7350 (Multi-table Models and Fixtures)




Change Properties
Action