# ActiveRecord's design allowing silent failure of object saves in associations

**URL:** <https://www.ruby-forum.com/t/activerecords-design-allowing-silent-failure-of-object-saves-in-associations/186134>\
**Category:** Rails\
**Created:** [April 1, 2010, 12:17am UTC](https://www.ruby-forum.com/t/activerecords-design-allowing-silent-failure-of-object-saves-in-associations/186134 "2010-04-01T00:17:28Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsimone](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/2bfe46/32.png) [@jsimone](https://www.ruby-forum.com/u/jsimone)\
**Post date:** [April 1, 2010, 12:17am UTC](https://www.ruby-forum.com/t/activerecords-design-allowing-silent-failure-of-object-saves-in-associations/186134/1 "2010-04-01T00:17:28Z")

</div>

I take issue with the faxt that in some cases ActiveRecord may  
automatically  
save records using “save” rather than “save!”. Specifically, this is  
when  
assigning an object to a “has\_one” relation, or adding an object to the  
collection vreated by the remaining “has\_\*” associations.

The automatic saving alone seems a bit questionable to me, but I’ll  
cover  
that second. The fact that it uses “save” rather than “save!” is a  
bigger  
problem.

Let me take the example a a “Bar” class that “has\_one :foo”. If i use  
Bar#foo=, if the foo fails validation I get a silent failure.

The only way to check for failure is to check for the return value of  
the  
assignment. That is really ugly. First of all that is very unexpected.  
Nobody whould ever just guess that one needs to check the return value  
of an  
assignment. Further the idiom of checking the return value of an  
assignment  
already exists in other languages where it is largly just a shorthand.  
So  
people familar with other languages would misinterpet the code.

It is also a very easy idiom to forget. People are very accustomed to  
assignments never failing without throwing an exception. Overall this  
whole  
thing severly violates the priciple of least surprise.

There is a similar case with the remainin has\_\* associations, but the  
problem is slightly less severe there, as at least the idioms needed  
(checking the return value of \<\< or of Baz#foos.push, etc) are less  
surprising. But it is still easy to forget to check in the first place.

I would really like it if there were some way to request that “save!” be  
used in place of “save” in these locations. I’m not sure how best to  
expose  
such an option, since existing code that expects the current behavior  
would  
broken by such a change. (Although I suspect there is much more code  
that is  
currenly silently failing to save in some cases, where throwing an  
exception  
would help to higlight the brokeness of the code.)

But I’m not entirely convinced that saving immediately is the correct  
thing  
to do. Why not just delay the saving until the object with the “has\__"  
association is also saved? The code nessisary to do so already exists  
because that is absolutely required in the case that the object with the  
"has\__” association is a new record. So why not just do that in all  
cases?

Am I just missing something here?