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 <[EMAIL PROTECTED]> wrote:
On 4/17/06, Francois Beausoleil <[EMAIL PROTECTED]> 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
