Django

Code

Ticket #9982 (assigned)

Opened 6 months ago

Last modified 2 months ago

Inconsistent behavior on model save depending on whether OneToOneField is a primary key

Reported by: sean@frontsquare.com Assigned to: mtredinnick (accepted)
Milestone: 1.2 Component: Database layer (models, ORM)
Version: 1.0 Keywords: OneToOneField primary_key IntegrityError
Cc: Triage Stage: Accepted
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

Description

Hi, When using a OneToOneField? to make one model extend another, I noticed a behavioral inconsistency depending on whether the related model's OneToOneField? was also the primary key or not.

The inconsistency is to do with when save() can be called on model instances. Consider the following example models:

class BaseModel(models.Model):
    pass

class ExtendedModel(models.Model):
    link = models.OneToOneField(BaseModel)

It is not possible to first instantiate these models and later on save them - an IntegrityError would be raised when saving the ExtendedModel?. E.g.,

o1 = BaseModel()
o2 = ExtendedModel(link=o1)
o1.save()
o2.save()

when o2 is saved it will raise an IntegrityError because it doesn't have a value for the primary key of the model it is related to. I think o1's primary key is copied when o2 is initialized, and is None at this point because o1 isn't saved yet.

However, if the definition of ExtendedModel? is changed so that the OneToOneField? is also the primary key, it now becomes possible to save the model instances in this order. To test this I changed the model definition as follows:

class ExtendedModel(models.Model):
    link = models.OneToOneField(BaseModel, primary_key=True)

When using this model definition it seems that o1's primary key is copied when o2 is saved, as opposed to when o2 is initialized. This inconsistency caused a lot of head scratching here.

Thanks! Sean

Attachments

Change History

01/07/09 20:12:16 changed by mtredinnick

  • owner changed from nobody to mtredinnick.
  • needs_better_patch changed.
  • status changed from new to assigned.
  • needs_tests changed.
  • needs_docs changed.

The second case shouldn't work either. I'll have to check whether it's really doing something sensible there (as opposed to just not raising an error). It may be because of something in place for model inheritance that it's working; I seem to recall we added an admin-related workaround that was a bit of a hack. In which case, it'll just need documentation.

Django cannot read your mind and does not automatically save things. So you do need to save something before using it as a reference. The first case is consistent and you should always save before using something as a related instance.

Leaving open until I understand and document (at a minimum) what's happening.

02/25/09 13:51:44 changed by

  • milestone deleted.

Milestone post-1.0 deleted

02/26/09 19:43:16 changed by jacob

  • stage changed from Unreviewed to Accepted.
  • milestone set to 1.1.

05/07/09 06:14:09 changed by jacob

  • milestone changed from 1.1 to 1.2.

Pushing to 1.2: this is an inconsistancy, not an outright bug.


Add/Change #9982 (Inconsistent behavior on model save depending on whether OneToOneField is a primary key)




Change Properties
Action