This issue has been addressed a number of times as patches in trac and emails to this mailing list.  A thorough search of both will turn them up.

--
Benjamin Curtis
http://www.tesly.com/ -- Collaborative test case management
http://www.agilewebdevelopment.com/ -- Resources for the Rails community



On Jul 28, 2006, at 3:11 PM, Michael Genereux wrote:

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


-----Original Message-----
[mailto:[EMAIL PROTECTED]] On Behalf Of Caio Chassot
Sent: Thursday, July 27, 2006 8:03 AM
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 mailing list

  


-- 
Michael Genereux
SimianCodex - Web Application Development
949-874-6268


_______________________________________________
Rails-core mailing list

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Reply via email to