Opened 9 months ago

Last modified 4 months ago

#29085 new Cleanup/optimization

Possible data loss on .save() with unsaved related model

Reported by: Jonas Haag Owned by: nobody
Component: Database layer (models, ORM) Version: master
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


  • Create unsaved model C
  • Assign unsaved related model P
  • Save related model P and C
  • Relationship is lost

This is similar to #25160 I guess?

I reproduced this with all versions of Django 1.6 up to master.

from django.db import models

class Parent(models.Model):

class Child(models.Model):
    parent = models.ForeignKey(Parent, null=True, blank=True, on_delete=models.CASCADE)
from .models import Parent, Child
from django.test import TestCase

class MyTest(TestCase):
    def test_save(self):
        child = Child()
        child.parent = Parent()
        # This makes the problem go away:
        # child.parent = child.parent

Attachments (1)

patch.diff (2.4 KB) - added by Jonas Haag 9 months ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 9 months ago by Jonas Haag

Type: UncategorizedCleanup/optimization

comment:2 Changed 9 months ago by Tim Graham

Triage Stage: UnreviewedAccepted

Changed 9 months ago by Jonas Haag

Attachment: patch.diff added

comment:3 Changed 9 months ago by Jonas Haag

Is this the correct approach? Or should we rather consider the behaviour a bug and not use the "prohibited error" in the first place?

comment:4 Changed 9 months ago by Tim Graham

Without knowing what an implementation might look like, I'd expect the save to work since the parent is saved before the child.

comment:5 Changed 4 months ago by Tim Graham

#29497 is a duplicate.

comment:6 Changed 4 months ago by Matthew Schinckel

I believe I hit the same issue today.

I have a set of related objects that I want to construct all of the forms for, validate all of them, and then save.

However, the reference to the primary object (which is still "connected" to the child instances) is removed when saving.

I _think_ it's got to do with Field.pre_save(self, model_instance, add) being called before saving: which uses field.attname, which is necessarily empty initially (because we don't have a primary key on the reference object, yet).

I'm going to play around, but I think it could be that a ForeignKey can have slightly different behaviour, where it falls back to the related (in-memory) object, if one exists, and field.attname is None.

Note: See TracTickets for help on using tickets.
Back to Top