Rails core - Apr 2006 - What are your expectations when updating related objects ?

Hello everyone !

I'm just wondering what your expectations would be if you saw that code:

def edit
  @contact = Contact.find(params[:id])
  @contact.phone.attributes = params[:phone]
  return if @contact.update_attributes(params[:contact])
  # handle validation errors
end

What do you expect the phones table to contain:  the old values or the
new values ?

I expected the new values, and I expected AR:B to save the child
object during the parent object's transaction.  What actually happens
is AR:B reloads the relations, thereby destroying the values that I
just set...

So, what should be the expected behavior here ?

Thanks !
--
François Beausoleil
http://blog.teksol.info/

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

On 4/17/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> Hello everyone !
>
> I''m just wondering what your expectations would be if you saw that
code:
>
> def edit
>   @contact = Contact.find(params[:id])
>   @contact.phone.attributes = params[:phone]
>   return if @contact.update_attributes(params[:contact])
>   # handle validation errors
> end
>
> What do you expect the phones table to contain:  the old values or the
> new values ?
>
> I expected the new values, and I expected AR:B to save the child
> object during the parent object''s transaction.  What actually
happens
> is AR:B reloads the relations, thereby destroying the values that I
> just set...
>
> So, what should be the expected behavior here ?
>
> Thanks !
> --
> François Beausoleil
> http://blog.teksol.info/
AR has never saved child objects automatically to my knowledge.  I
usually put both saves in a transaction.

--
Rick Olson
http://techno-weenie.net

On 4/17/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> I'm just wondering what your expectations would be if you saw that
code:
>
> def edit
>   @contact = Contact.find(params[:id])
>   @contact.phone.attributes = params[:phone]
>   return if @contact.update_attributes(params[:contact])
>   # handle validation errors
> end
>
> What do you expect the phones table to contain:  the old values or the
> new values ?
As Rick already said, AR currently requires you to save the individual
AR instances.

It would make sense to have the whole tree saved when you save the
top-level object, otherwise you have to _know_ which objects are
actually tied to database tables and which are just "normal"
properties. If one of the purposes of an object-relational mapper is
to let the developer concentrate on the application code rather than
the database, this is one area where we lose that advantage.

However, there are a few isues I can forsee if  this was implimented.
First there is the potential for huge SQL queries to be made
unecessarily. It may also cause issues when the objects in the subtree
are associated with more than one parent object. While these issues
could be resolved, is it worth it to spend time on such things?

I, for one, would trade being able to save the whole tree with one
call to save for the other (probably more useful and time-saving)
improvements to AR that would likely get dsplaced in order to
impliment this. Besides, if you really need this on a specific set of
model classes, it's possible to impliment the behavior using the
callbacks; and the risks I mentioned would at least be localized to
that one specific hierarchy.

--
Regards,
John Wilger
http://johnwilger.com

-----------
Alice came to a fork in the road. "Which road do I take?" she asked.
"Where do you want to go?" responded the Cheshire cat.
"I don't know," Alice answered.
"Then," said the cat, "it doesn't matter."
- Lewis Carrol, Alice in Wonderland

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Here is my problem with such a system.

If we took this code bit...
> def edit
>   @contact = Contact.find(params[:id])
>   @phone = @contact.phone
>   @phone.attributes = params[:phone]
>   return if @contact.update_attributes(params[:contact])
>   # handle validation errors
> end
As far as @contact.phone is concerned there is no difference between the
caller keeping the reference or acting on it immediately. The @contact would
keep the reference to @contact.phone (I believe it does this already) which
is the same reference in @phone. So, in the above example, one would assume
that the changes in @phone would be ignored since it seems to be its own
independent object.

So, at the end of this, @phone''s changes would be saved with the saving
of
@contact. This is totally unexpected.

The current setup might take a moment to go... "oh yeah! duh!" but I
don''t
believe it would break expectations the way that the alternative would.

-hampton.

On 4/17/06, John Wilger <johnwilger@gmail.com>
wrote:
>
> On 4/17/06, Francois Beausoleil <francois.beausoleil@gmail.com>
wrote:
> > I''m just wondering what your expectations would be if you saw
that code:
> >
> > def edit
> >   @contact = Contact.find(params[:id])
> >   @contact.phone.attributes = params[:phone]
> >   return if @contact.update_attributes(params[:contact])
> >   # handle validation errors
> > end
> >
> > What do you expect the phones table to contain:  the old values or the
> > new values ?
>
> As Rick already said, AR currently requires you to save the individual
> AR instances.
>
> It would make sense to have the whole tree saved when you save the
> top-level object, otherwise you have to _know_ which objects are
> actually tied to database tables and which are just "normal"
> properties. If one of the purposes of an object-relational mapper is
> to let the developer concentrate on the application code rather than
> the database, this is one area where we lose that advantage.
>
> However, there are a few isues I can forsee if  this was implimented.
> First there is the potential for huge SQL queries to be made
> unecessarily. It may also cause issues when the objects in the subtree
> are associated with more than one parent object. While these issues
> could be resolved, is it worth it to spend time on such things?
>
> I, for one, would trade being able to save the whole tree with one
> call to save for the other (probably more useful and time-saving)
> improvements to AR that would likely get dsplaced in order to
> impliment this. Besides, if you really need this on a specific set of
> model classes, it''s possible to impliment the behavior using the
> callbacks; and the risks I mentioned would at least be localized to
> that one specific hierarchy.
>
> --
> Regards,
> John Wilger
> http://johnwilger.com
>
> -----------
> Alice came to a fork in the road. "Which road do I take?" she
asked.
> "Where do you want to go?" responded the Cheshire cat.
> "I don''t know," Alice answered.
> "Then," said the cat, "it doesn''t matter."
> - Lewis Carrol, Alice in Wonderland
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core