Brian Chapados wrote:
In your example, you're updating both the Author and Story tables. In this
case, the association is stored in the Story table (author_id). Thus, I
think that doing a final "a.save" with the intention of saving changes to
both the Author and Story is impossible, since the Author table doesn't
store any info about the story. I might be missing something, but I don't
see a way around doing 2 database calls in this case, so your validations
will trigger as each modification is saved.
Yes, in the case of doing updates to existing records, "a.save" does
not know about the association with s, so s does not get saved.
In the case of new records though, the "<<" operator, or a.build,
(or maybe even s.author=a) all create *somewhere* the knowledge within
the Author record "a" that the Story record "s" is needs to be saved.
In looking at this further, I'm starting to see a little of the
machinations behind the scenes, but still am not seeing what
magic flag makes the save cascade or not.
Basically, if I create a new Author "a", then a new Story and associate
it with that Author, an array @stories (sibling of a's @attributes)
pops into existence. I figured it was the existence of that extra
array attached to "a" that made the a.save save the story as well.
But I just tried with a pre-existing "a" and "a.stories", and once you
access a story in "a", that array pops into existence attached to the
"a" object as well. But in this case the a.save still ignores changes to
a's @stories array.
So I'm still confused as to what rails is actually doing, but I'm
probably getting pretty close to beating a dead horse at this point.
It was a good mental flagellation exercise anyway :-)
-glenn
_______________________________________________
Sdruby mailing list
[email protected]
http://lists.sdruby.com/mailman/listinfo/sdruby
