Anyone have any thoughts on the new "dirty objects" functionality in rails 2.1? One writeup is here:
http://ryandaigle.com/articles/2008/3/31/what-s-new-in-edge-rails-dirty-objects Seems pretty nice in theory, but essentially unusable in that rails-does-it- like-this-except-when-it-doesn't way that has bitten me more than once, and mentioned by several of the commenters. Basically, rails will know a model object is dirty if you change any of its attributes via "attr=", but not if you mutate it some other way (e.g. "attr.upcase!"). You can force rails to pay attention per attribute with "model.attr.will_change!", but seriously... we have to decide ahead of time which attributes might be changed that way? Or remember six months down the road when adding an upcase! to also call will_change? Partial Updates functionality apparently uses the same mechanism, so has the same problem. One of the commenters summarized: > # > alexv – June 02, 2008 @ 12:16 PM > > About will_change! – it is bad. Think about why it is there? just to cover > alternative way to modify attribute. What if tomorrow it will be ANOTHER way > to modify attribute, something like AOP or else. In environment, where setter > is NOT in full control of attribute there is no way to reliable implement > “changed?” without caching original value. (Getting it from database per > demand would be another way, but it is slightly different – for example it > returns changed if database was modified by another transaction). > > Thus, I would be looking for the following setup switch: > > Mode-1 Old-way: no original value caching – good for memory, easy to code, > consistent, hard on db connection because of full save. “changed?” is > optional, not reliable, not used during “save” > > Mode-2 Consistent dirty check. Full caching of original values – hard on > memory. “Changed?” is reliable and used for partial save – good for DB > connection performance. > > Mode-3 Inconsistent dirty check with flags – as implemented today. Good for > memory, good for performance. Unreliable behaviour unless specially coded > (“will_change!”). Unreliable behaviour in AOP future (my guess). > > Sorry, I did not checked yet if there is possibilities to switch between > modes. Mode-3 is not my type of doing business, but if somebody will use it > with FULL understanding of its limitations – good luck. --~--~---------~--~----~------------~-------~--~----~ SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby -~----------~----~----~----~------~----~------~--~---
