You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would actually argue against adding this feature.
As shown in the README, implementing your own caching with Rails.cache.fetch (or a DalliClient for example in a non-Rails app) is dead simple, and I don't see a reason to slow down JB's processing time by having it calculate what we can only guess is the best way to hash your specific collection or object to form a unique key.
If your Rails.cache.fetch key is colliding easily, you should try changing up how you generate your key, perhaps with a more dynamic approach. At the object level, using "--" is good enough to start with, and at the collection level, using "-" can also be good enough. A single SQL query to select the MAX(updated_at) of a table for the collection cache key can be 0.1-10ms on average depending on your infrastructure, maybe 50-100ms if dealing with higher than normal network latency, shoddy web hosting, or GBs worth of data rows in a single table.
Other solution like JBuilder and RABL has some caching function built-in
And they do make the caching key different so that it won't collide so easily
The text was updated successfully, but these errors were encountered: