It makes sense! I have a debt entity in my application and payments this entity can happen three or more times in parallel (stupid brazilian banks, don't ask me why they do it).
Since I have to keep a cache column of the paid value for the debt, I have 25 workers (sidekiq) that can call `increment!(:paid_value, paid_value)` and it should keep the total paid value. I'm not sure if it will be a problem to happen something like that: debt.paid_value # => 100.0 debt.increment!(:paid_value, 100.0) # => 300.0 We can have problems if other columns relies on that value. Let suppose I have another column called paid_interest and with the paid_value, I get the total paid: debt.paid_value # => 100.0 debt.paid_interest # => 10.0 debt.total_paid # => 110.0 debt.increment!(:paid_value, 100.0) # => 300.0 debt.total_paid # => 310.0 The paid_interest in this case is updated in another process. It's a contrived example but if that's the case, I will need to reload the entire record to get the right total paid. At least some documentation telling that increment and increment! are subject to race conditions is needed. On Tuesday, January 22, 2013 7:19:28 PM UTC-2, Brendon Murphy wrote: > > > On Tuesday, January 22, 2013 1:05:50 PM UTC-8, ajsharp wrote: >> >> By "bust the cache", do you just mean update the counter? >> > > I was referring to updating the updated_at timestamp, as the default > ActiveRecord #cache_key integrates that column if available to help ease > your cache expiration. In this context I mean a cache of > memcache/redis/etc, not an instance attribute cache. > > > On Tuesday, January 22, 2013 1:05:50 PM UTC-8, ajsharp wrote: >> >> >> On Tue, Jan 22, 2013 at 11:45 AM, Brendon Murphy <xter...@gmail.com>wrote: >> >>> Side note on the updated_at column; the .update_counters method relies >>> on .update_all, so it does not bump the updated_at timestamp. This is not >>> that unexpected since the column timestamping is handled via the .create >>> and .update methods for ActiveRecord::Base. While I agree it seems bad to >>> have public methods changing the record without changing the updated_at >>> (thereby breaking the cache key), doing so would be inconsistent with some >>> similar AR mechanisms already in place. >> >> >> Yea, I've never *really* understood the AR distinction between things >> that update the timestamp and things that don't. In my mind, it's a blurry >> line that is defined somewhere along the lines of "has the model really >> been updated, or did you just update a counter?". >> >> >>> Given a vacuum though, I'd prefer to bust the cache implicitly when I'm >>> bumping a counter. >>> >> >> By "bust the cache", do you just mean update the counter? >> > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/cgGlE486aGkJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
