Cache is running query on view fragment cache hit anyway

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Cache is running query on view fragment cache hit anyway

Steve-2
I've been developing with Rails for a few years now, but one part I haven't used is view fragment caching.

I'm using it now, and I'm seeing what I think is undesirable behavior, but I need someone with experience to tell me if it's supposed to be this way.

I'm caching a collection, and it runs the query to generate the cache key (count, max updated_at) as expected, but then regardless of whether there is a cache hit, it still runs the main query, and if there are includes, it runs those queries, too.  If the view fragment is being served from the cache, then those queries are just wasted time.  Has it always been like this?

I can work around it by using "<% cache @collection.cache_key do %>" instead of "<% cache @collection do %>", but it seems like it shouldn't run the query in the first place.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/cf613f24-c38f-4961-a63a-e52aee5a39cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Cache is running query on view fragment cache hit anyway

Steve-2

Yeah, I created a Rails 3 and Rails 4 project.  Rails 3 doesn't support #cache_key on collection, and Rails 4 uses each individual element to create a cache key.

I set up byebug and traced the #cache view helper.  The reason the relation is being loaded is because the helper eventually calls #to_a on the relation, which of course results in the query being executed.

Looks like the best solution is using #cache_key directly.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/5421611e-cbc9-4bda-9b92-fc5ae8238bdd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Cache is running query on view fragment cache hit anyway

Rob Jonson
In reply to this post by Steve-2
Possibly related: Rails 5 has new (improved) behaviour for collection caching

<%= render partial: :post, collection: @posts, cached: true %>

will cache
although

<%= collection: @posts, cached: true %>

will not cache

more info on how it works and the benefits here:
https://blog.appsignal.com/2018/08/14/rails-collection-caching.html


On Monday, 24 September 2018 16:25:13 UTC+1, Steve wrote:
I've been developing with Rails for a few years now, but one part I haven't used is view fragment caching.

I'm using it now, and I'm seeing what I think is undesirable behavior, but I need someone with experience to tell me if it's supposed to be this way.

I'm caching a collection, and it runs the query to generate the cache key (count, max updated_at) as expected, but then regardless of whether there is a cache hit, it still runs the main query, and if there are includes, it runs those queries, too.  If the view fragment is being served from the cache, then those queries are just wasted time.  Has it always been like this?

I can work around it by using "<% cache @collection.cache_key do %>" instead of "<% cache @collection do %>", but it seems like it shouldn't run the query in the first place.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/dcf902c2-9fd2-4841-a9db-51e9f6c01223%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.