Use a more precise generated cache key #939
Conversation
| @@ -63,7 +63,7 @@ def is_fragment_cached? | |||
| end | |||
|
|
|||
| def cache_key | |||
| (@klass._cache_key) ? "#{@klass._cache_key}/#{@cached_serializer.object.id}-#{@cached_serializer.object.updated_at}" : @cached_serializer.object.cache_key | |||
| (@klass._cache_key) ? "#{@klass._cache_key}/#{@cached_serializer.object.id}-#{@cached_serializer.object.updated_at.strftime("%Y%m%d%H%M%S%9N")}" : @cached_serializer.object.cache_key | |||
There was a problem hiding this comment.
Unfortunately this means if updated_at is nil, you're gonna have a Bad Time. If that's something we should consider, I can update this method to be a bit more resilient.
There was a problem hiding this comment.
Yeah, that would be awesome if we could make it more resilient 😄
|
@aaronlerch sorry for taking so long to review it, I was rushing with some new feature myself, but I'm really in favor of this PR. |
|
No problem -- yeah, I'll make the change and update the pull request. I'm travelling for a few days so I'll get to it as soon as I'm able. Thanks! |
|
Great! Thank you! ❤️ |
aaronlerch
force-pushed
the
default-cache-key
branch
from
11d25b7 to
2e803eb
Compare
|
Hold on, I think I messed up my attempt to rebase off master. |
…w #to_s to achieve more accurate precision
aaronlerch
force-pushed
the
default-cache-key
branch
from
2e803eb to
6892ca3
Compare
|
Okay, assuming Travis likes my pull request, it should be ready now @joaomdmoura -- including the change to make the use of |
|
Amazing @aaronlerch! I'm merging it! ❤️ |
Use a more precise generated cache key
This change updates the default generated cache key (when the
key: 'foo'option is specified and the object's#cache_keyimplementation isn't used) to use a more precise version ofupdated_at. By default, it was invokingupdated_at.to_swhich ends up with a cache key value likecache-key-prefix/807130-2015-05-27 18:11:05 UTCThis effectively means, if someone specifies a cache key in the serializer (which is really just a cache key prefix value -- I'll save that discussion for another PR perhaps ;) ) it will only be cached with a precision to the minute. So if I have a model and it gets cached, and I update it within the same minute, the cache will not be considered invalid and my model changes will not be reflected.
The ActiveRecord implementation of the default cache key, as you can see here https://github.com/rails/rails/blob/master/activerecord/lib/active_record/integration.rb#L55 , allows some customization but defaults to
updated_at.utc.to_s(:nsec)which gives a much greater precision. In the example I gave above, it would becache-key-prefix/807130-20150527181105000000000.Since this gem doesn't have the dependencies to leverage the
:nsecformat helper, I leveraged the same format string to use here. (Currently using a magic string, since the only duplicate copies are in tests.)I specifically did not update the cache_key to use
#utc, but if that's desired I can update it to use that as well.I also fixed up some of the tests. The test harnesses were written specifically using
updated_at.to_iwhich allowed some implicit assumptions about cache invalidation to be encoded into the tests, which failed (rightly so) when I made the change to use a higher precision value.✨ 🕒 ✨
Thanks!
Aaron