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<javascript:> > > 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/-/XR5YHOsuTXQJ. 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.
