Cannot save value via OneToOneField

[Peter Baumgartner]

Trying to save a value into a OneToOne child instance via it's parent has no effect.

>>> p = Place.objects.get(pk=1)
>>> p.restaurant.waiters
10
>>> p.restaurant.waiters = 5
>>> p.save()
>>> p.restaurant.waiters
10
>>> p.restaurant.save()
>>> p.restaurant.waiters
10

Saving via the child works as expected.

>>> r = Restaurant.objects.get(pk=1)
>>> r.waiters
10
>>> r.waiters = 5
>>> r.save()
>>> r.waiters
5

[Vadim Fint]

Confirmed with latest SVN (r7003). Value does not even save in the model.

>>> p = Place.objects.get(pk=1)
>>> p.restaurant.waiters
10
>>> p.restaurant.waiters = 5
>>> p.restaurant.waiters
10

[Vadim Fint]

Fast fixup. I'm sorry I have no a lot of time to test this, but works fine for me.
So, please make your checks :).

db/models/fields/related.py

@@ -126 +126 @@
     def __get__(self, instance, instance_type=None):
         if instance is None:
             raise AttributeError, "%s must be accessed via instance" % self.related.opts.object_name
+        try:
+            self.__cached_rel_obj
+        except AttributeError:
+            params = {'%s__pk' % self.related.field.name: instance._get_pk_val()}
+            rel_obj = self.related.model._default_manager.get(**params)
+            self.__cached_rel_obj = rel_obj
 
-        params = {'%s__pk' % self.related.field.name: instance._get_pk_val()}
-        rel_obj = self.related.model._default_manager.get(**params)
-        return rel_obj
+        return self.__cached_rel_obj
 
     def __set__(self, instance, value):
         if instance is None:

[Vadim Fint]

Fast fixup.

[Vadim Fint]

More accurate fixup

db/models/fields/related.py

@@ -126 +126 @@
     def __get__(self, instance, instance_type=None):
         if instance is None:
             raise AttributeError, "%s must be accessed via instance" % self.related.opts.object_name
+        cache_name = self.related.field.get_cache_name()
+        try:
+            return getattr(self.related, cache_name)
+        except AttributeError:
+            params = {'%s__pk' % self.related.field.name: instance._get_pk_val()}
+            rel_obj = self.related.model._default_manager.get(**params)
+            setattr(self.related, cache_name, rel_obj)
+            return rel_obj
 
-        params = {'%s__pk' % self.related.field.name: instance._get_pk_val()}
-        rel_obj = self.related.model._default_manager.get(**params)
-        return rel_obj
-
     def __set__(self, instance, value):
         if instance is None:
             raise AttributeError, "%s must be accessed via instance" % self.related.opts.object_name

[MockSoul <mocksoul@…>]

Both prev diffs were invalid, sorry.

[Jacob]

Yeah, setting attributes on related objects doesn't automatically save them; this'll happen with an FK or M2M, too. You need to do something like:

r = place.restaurant
r.waiters = 5
r.save()

[Vadim Fint <mocksoul@…>]

Replying to jacob:

Yeah, setting attributes on related objects doesn't automatically save them; this'll happen with an FK or M2M, too. You need to do something like:

This is confusing me a little. Why did such design decision was choosen?

[James Bennett]

Replying to Vadim Fint <mocksoul@gmail.com>:

Replying to jacob:

Yeah, setting attributes on related objects doesn't automatically save them; this'll happen with an FK or M2M, too. You need to do something like:

This is confusing me a little. Why did such design decision was choosen?

It's consistent; Django doesn't push changes to an object's field values down to your DB until you call save(); this is the case with any field type, and is generally considered useful because it means that you don't end up doing a hit to your DB every time you assign to an attribute.

[daotranbang@…]

Replying to ubernostrum:

Replying to Vadim Fint <mocksoul@gmail.com>:

Replying to jacob:

Yeah, setting attributes on related objects doesn't automatically save them; this'll happen with an FK or M2M, too. You need to do something like:

This is confusing me a little. Why did such design decision was choosen?

It's consistent; Django doesn't push changes to an object's field values down to your DB until you call save(); this is the case with any field type, and is generally considered useful because it means that you don't end up doing a hit to your DB every time you assign to an attribute.

I think he mean to ask why did this design was choosen:

varname = object.related_name
varname.key = value
varname.save()

instead of

object.related_name.key = value
object.related_name.save()