> 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;
Yes, that was my thought too, after the first comment. I've come to the conclusion that the second query is unnecessary if we just update the in memory copy directly (without the DB update) and use the Base.update_counters to "safely" update the counters. If the in memory copy is stale, even after the counter cache has updated it, then it would be stale anyways and there is nothing we can do. As long as the database has the correct value then all should be good. One question here, is there any particular reason, why the has_many associations build method only associates the parent object by id rather than by object? This is a potential issue when updating the in memory copy. Although the bi-directional associations may nullify this question. blog = Blog.create puts blog.object_id # => 103230460 post = blog.posts.build puts post.blog.object # => 103511790 > 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 Great! A good place to start looking at. Thanks for the link. Thanks, Adam On Dec 1, 12:06 pm, acechase <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
