Given that even the most basic, multiuser apps hit concurrency issues
with editing different fields in the same record, I was surprised that
version locking was the only level of support Rails offered.
I would *love* to PDI field level change checking (I've done it before
on another framework) and also updating Base to only UPDATE fields that
have changed. While it may sound funny, I'm a gung-ho person and would
just need to be pointed in the direction of how to make a plugin. I
wander through the ActiveRecord code all the time but not all of Rails.
I was pondering adding support with a patch and have some really great
ideas but if it didn't get accepted, I didn't want to waste the time.
Also, how do I check to see if someone else hasn't already started a
plugin/gem/patch for the same issue?
Bob Silva wrote:
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
--
Michael Genereux
SimianCodex - Web Application Development
949-874-6268
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
