On Tue, Jun 10, 2014 at 12:25 PM, Malcolm Box <malc...@tellybug.com> wrote: > On Monday, 9 June 2014 03:08:21 UTC+1, Russell Keith-Magee wrote: >> >> >> On Sun, Jun 8, 2014 at 10:34 PM, Malcolm Box <mal...@tellybug.com> wrote: >>> >>> I'm confused by Django's behaviour when saving related models. Take for >>> example: >>> <snip details of classes and saving behaviour> >>> I kind of understand this, but it's not obvious to me why Django doesn't >>> at least try to save the related object first >> >> >> Ok - so how does Django decide that the related object needs to be saved? >> >> If it saves all related objects, then saving one object could result in a >> save call being invoked on every object in the database (since y points to >> x, which points to a, which points to b,…). I hope we can agree that a >> cascading save like this would be a bad idea. >> >> If it's not *every* related object, then we need to make a decision - >> which ones get saved? Ok - so lets say we just save the newly created >> objects (i.e., objects with no primary keys. >> >> That means that the following would work: >> >> x = X(value=37) >> y = Y(x=x) >> y.save() >> >> and on retrieval, y.x.value == 37. Sure - that makes sense. But what >> about: >> >> x = X(value=37) >> x.save() >> x.value = 42 >> y = Y(x=x) >> y.save() >> >> and on retrieval, y.x.value == 37. Huh? Why? Oh - it's because in *that* >> case, x was already in existence, so it wasn't re-saved as a result of y >> being created. So now we've got inconsistent behaviour, depending on when >> save() has been called on an object. > > > Sure, that would be the side effect of assigning a pre-existing object. The > use case I'm thinking of is creating an entire tree of un-saved objects in > memory, and then having save() on the root Do The Right Thing. If that was > inconsistent with assigning pre-existing objects, I could live with it.
I almost replied to Russell's reply to make this point explicitly clear - BDFL advice tends to be fully accurate. It is an error to assign an unsaved object as a relation of another object (the saved state of that object is not relevant) for the reasons that Russell explained. I don't know why it does not raise a runtime error at this point, it would be possible. Once you have assigned an unsaved object, behaviour is undefined - the behaviour is only defined when saved objects are assigned as a relation - and therefore anything can happen after that point. When you have undefined behaviour, DTRT is not possible (if you can do the right thing, you can define the behaviour). That makes trees of unsaved related objects right out! Cheers Tom -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAFHbX1Loc4HBC4iMeJkj%2BpraRGTy1YZbF1O5%2B6xkToSrd3XGEw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
