> Robert Walker wrote: >> Besides this. According the the Rails docs, increment_counter is >> typically used for caching aggregate values. That's not the case here >> since the field to be incremented is not related to an associated model. >> The increment_counter would make sense for things like caching the count >> of comments on a post model to prevent the SQL query that would be >> required to count the associated comments. >> >> And, of course, that race condition exists in your console experiment, >> but that's not an issue in the controller method I presented earlier. >> The @poem instance would be garbage collected at the end of the >> request-response cycle. Other methods would have to reload from the >> database anyway. So I don't see a problem using the increment! method >> here. >> >> ------------------------------ >> def show >> @poem = Poem.find(params[:id]) >> @poem.increment!(:view_count) >> ... >> ... >> end >> ------------------------------ > > Disregard this.
Too late. I already responded :) > I see the issue presented by Philip Hallstrom now. Makes > sense. Maybe we should consider deprecating increment! given the race > condition due to multi-threading/multi-processes. Maybe. But then again it may have it's uses. Maybe you know what you're doing and really just want to update the model (assuming the non-bang version). I think it would be a good idea for the docs to mention the race condition and point people to increment_counter. increment! could also simply hand off to increment_counter, but that might have some negative side affects for existing code that rely on increment/increment!. I don't know.... -philip -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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-talk?hl=en.
