I'm curious to know if "dirty" checking was considered during the design process of AR. It would add performance benefits (configurable?) for larger tables and associations in a write heavy environment especially if you have text or blob fields in your tables. Anyone care to PDI this as a plugin?
Bob Silva http://i.nfectio.us/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Caio Chassot Sent: Thursday, July 27, 2006 8:03 AM To: rails-core@lists.rubyonrails.org Subject: Re: [Rails-core] Re: Why are has_one objects resaved when the parentis saved? On 2006-07-27, at 11:56 , Josh Susser wrote: > That's a valid point. But did you read Jonathan's patch? It > covers that case where you're dealing with new records just fine. > I think the issue he was correcting was that has_one *always* saves > the child object, not just for new records. Strictly, it does not *always* save the child, only if it's been *loaded*. It checks the association ivar directly, meaning it does not go through the accessor, and therefore does not try to load it. Saving loaded associations is a cheap way to make sure you save everytime a change *could have* happened. Without a dirtyness check, I'd say that's good enough. The alternative would be a handcoded dirtyness check, something like: assoc_record.class.find(record.id).attributes.all? { |(k, v)| assoc_record.send(k) == v } Which quickly becomes expansive. _______________________________________________ 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
