Keep in mind that multiple instances of rails will be running on all but the simplest applications, so relying on in-application information will be broken from the start since each instance of the application will have it's own in-memory objects.
I agree it would be nice to not need to reload the object after an increment/decrement call is made, but I think the proper solution would be to retrieve the new value from the database after the UPDATE has occurred. One way I think this could be done is by issuing a query similar to this: UPDATE users SET score = score + 1 WHERE users.id = 1; SELECT users.score FROM users WHERE users.id = 1; Then the return value from that query could be used to update the in- memory object. You still have two separate db operations, but at least they come through in one back and forth trip to the db, which is where the wost of the performance penalty occurs in this type of sequence (at least, that's what my profiling has shown). Also note that this new in-memory value is again immediately stale upon retrieval and you'd to do a select for update inside a transaction if you wanted to use that value to write back to the db. As for the bi-directionality of in-memory AR objects, you should check out the parental-control plugin, which while incomplete, covers quite a bit of what is needed to support bi-directional associations in rails: http://github.com/h-lame/parental_control/tree/master Cheers, Andrew On Nov 30, 6:15 pm, adamc <[EMAIL PROTECTED]> wrote: > Hi, > > I've started looking at the counter_cache implementation with the > original intention to have the increment, decrement update the model > in memory (without relying on a reload) to be called. > > You can see a sample of the bug here:http://gist.github.com/30580. > > While starting to look at this issue (my first real look at the rails > code base) I'm wondering if anyone has already done any initial > thinking of this issue or has an idea of what they would like to see > happen here. In my initial thinking (I haven't looked at the > association proxy/collection enough) there could be a bi-directional > link for the has_many/belongs_to reflections/assocations. > > Looking around I noticed a small bug with custom counter cache names > not be utilized in the record with the has_many association. There is > currently no way for this association/reflection object to know about > the belongs_to settings where the counter_cache name is set. > > An easy way to quickly solve this is to add a :counter_cache => > 'custom_name' to the has_many method call. What are your thoughts on > this proposed change for the has_many options? > > Thanks, > Adam --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
