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