n8 / multi_fetch_fragments Goto Github PK

Ruby 1.9.3/Rails 3.2

I am creating a PDF within a delayed_job job, and to do this I am generating HTML content within the job. This means I cannot rely on one of the provided controllers and must instantiate my own ActionView:

action_view = ActionView::Base.new(Rails.configuration.paths["app/views"]) action_view.class_eval do
include Rails.application.routes.url_helpers
include ApplicationHelper

  def protect_against_forgery?
    false
  end

end
action_view.render(:template => 'presentations/print_selections', :layout => nil, :format => 'html',
:locals => {
:presentation => presentation,
:title => title,
:selector => selector
})

The template listed above contains a call to multi_fetch_fragments. If I add a hardcoded string to a custom cache_key like so

<%= render partial: 'presentations/cache_partials/pdf/talent', collection: category.talents,
cache: Proc.new { |talent| [talent, 'pdf'] },
:locals => {:presentation => presentation, :selector => selector} %>

I get this error:

Error message: undefined method fragment_cache_key' for nil:NilClass /app/vendor/bundle/ruby/1.9.1/gems/multi_fetch_fragments-0.0.16/lib/multi_fetch_fragments.rb:36:inblock in render_collection_with_multi_fetch_cache'
/app/vendor/bundle/ruby/1.9.1/gems/multi_fetch_fragments-0.0.16/lib/multi_fetch_fragments.rb:24:in each' /app/vendor/bundle/ruby/1.9.1/gems/multi_fetch_fragments-0.0.16/lib/multi_fetch_fragments.rb:24:inrender_collection_with_multi_fetch_cache'
/app/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.11/lib/action_view/renderer/partial_renderer.rb:234:in block in render' /app/vendor/bundle/ruby/1.9.1/gems/actionpack-3.2.11/lib/action_view/renderer/abstract_renderer.rb:38:inblock in instrument'

If I use the default cache_key then it works.

I tried adding a variable key (rather than a hardcoded string) and found failure as well.

Any reason why a custom action view would cause errors with custom keys?

Thanks.

I have a Rails 4 app and I'm using the following render call:

= render @photographs, cache: true, cache_options: { expires_in: 10.minutes }

However the cache expiry option never makes it to the write call, as far as I can tell (notice how the other cache reads/writes have the expiry option noted in the logs):

Cache write: views/photographs/2007-20130514075157325004000/86a3d50c854dde8d1587667ed0367762
Cache write: views/photographs/2006-20130514074910243807000/86a3d50c854dde8d1587667ed0367762
Cache write: views/photographs/2005-20130514074815238693000/86a3d50c854dde8d1587667ed0367762
Cache write: views/photographs/2004-20130514074438247143000/86a3d50c854dde8d1587667ed0367762
Cache write: views/photographs/2003-20130514074433630211000/86a3d50c854dde8d1587667ed0367762
...
  Rendered photographs/_photograph.html.slim (143.5ms)
  Rendered photographs/index.html.slim within layouts/application (593.7ms)
Cache read: views/nav/explore/photographs/b1a68cde36235e0fcb82a2496d24f1d2 ({:expires_in=>600 seconds})
Read fragment views/nav/explore/photographs/b1a68cde36235e0fcb82a2496d24f1d2 (0.5ms)
Cache write: views/nav/explore/photographs/b1a68cde36235e0fcb82a2496d24f1d2 ({:expires_in=>600 seconds})

I've tried looking myself but I've not found the cause yet. Any ideas?

I see 0.0.14 up on rubygems but no corresponding commits here. Could you please push your changes?

I am getting this error after upgrading to 0.0.14

here is the line in question

<%= render partial: 'activity', collection: @activities, cache: true %>

I'm a bit confused with the documentation. Am I still able to use this gem with a cache block of code for example like this:

<% cache(['v1', @orders.count]) do %>
    <% if @orders.count < 1 %>
        <div class="row-fluid">
            ...
        </div>
    <% end %>
<% end %>

Hi,
I have used Redis instead of Memcached,my question is is this gem works with only Memcached or it will work with Redis as well?

Hey Nate, I just added this to project of mine, and found a small bug.

The Rails.cache.read_multi() call actually takes a list of parameters, not an array. The Dalli cache store that I'm using then fails to return any results.

The easy fix is to splat the keys array:

result_hash = Rails.cache.read_multi(*(keys_to_collection_map.keys))

Then it works like a champ!

Depending on how many fragments are cached, items are removed from the collection. This leaves the collection with fewer than the items it started with, sometimes as little as zero items.

It would be nice if the collection was not destroyed during the process, so it can be used again, or used for other reasons.

multi_fetch_fragments worked with the cache_digests gem for a while, but no longer seems to include the cache digest with what ships in Rails 4.

I'm working on why this is, but wanted to check if anybody had an idea for how to restore support.

It looks like fragment_name_with_digest has been made a private method of ActionView::Helpers::CacheHelper

I'm seeing this deprecation warning while upgrading to Rails 5:

DEPRECATION WARNING: alias_method_chain is deprecated. Please, use Module#prepend instead. From module, you can access the original method using super. (called from block in module:MultiFetchFragments at /home/project/vendor/cache/multi_fetch_fragments-59612d54fc3f/lib/multi_fetch_fragments.rb:5)

I was playing around and doing some performance measurements, but came across this error in my test app:

dalli (2.6.0) lib/active_support/cache/dalli_store.rb:270:in `force_encoding'
dalli (2.6.0) lib/active_support/cache/dalli_store.rb:270:in `expanded_key'
dalli (2.6.0) lib/active_support/cache/dalli_store.rb:128:in `block in read_multi'
dalli (2.6.0) lib/active_support/cache/dalli_store.rb:128:in `each'
dalli (2.6.0) lib/active_support/cache/dalli_store.rb:128:in `inject'
dalli (2.6.0) lib/active_support/cache/dalli_store.rb:128:in `read_multi'
multi_fetch_fragments (0.0.9) lib/multi_fetch_fragments.rb:32:in `render_collection_with_multi_fetch_cache'

It seems that the 2.6.0 bump brought in petergoldstein/dalli@aa7ff87 which now requires that the given keys to cache.read_multi and cache.write must be mutable. I attempted to make a fix, and normally would have done a pull request, but after the fix the performance became worse: bwillis@02d8687

Thoughts?

Hey,

this looks extremely nice. One theoretical question: Does multi_fetch_fragments also handle the new Rails 4 way of including a digest of the rendered template and it's dependencies into the cache key?

This behavior is abstracted for Rails 3.2 into the Cache Digests gem as well.

Thanks for your answer in advance.

Best regards,
Thomas

I have the following scenario:
A partial rendered ( called _folder_results_table.html.erb) every 5 ms in a js view like this.
"<%= j(render('folder_results_table')) %>";
and within that partial I'm trying to render and cache a collection of hashes using this gem, like this:
<%=
render :partial => "result_asset", collection: @somegroups, as: :result,
locals: {group_name: group_name, group_name_to_id: group_name_to_id }
, cache: Proc.new { |item| [ item[:result][:asset], item[:job][:id], item[:name_collides] ] }
%>

The problem is that the digest for the parent cache is calculated in every item of the collection as given by the Rails log

Cache digest for folders/_folder_results_table.html: 44ebc3150678502edd950093fd618343
Cache digest for folders/result_asset.html: 46e854eaa29fb504ccd6786e10617704
... a 100 items later
Cache digest for folders/_folder_results_table.html: 44ebc3150678502edd950093fd618343
Cache digest for folders/result_asset.html: 46e854eaa29fb504ccd6786e10617704.

Why does the digests needs to be calculated in every item? This slowing the process some much that it's faster to not cache the result_asset partial at all. Is there any workaround, or I'm just stuck to not caching the collection which in real production data can have hundreds of elements and will be rendered every 5 sec or so (I know this is bad but right now can not be changed).

Best Regards

I'm using memcached, dalli, heroku, and s3 to serve my images using your gem. I am not 100% sure it is your gem yet because there are a lot of elements involved. What I think is happening though is some of the caches are getting missed on call and staying improperly cached. I have it in a dropdown that is called on keyup, is that a bad idea to use with this gem?

With Rails 3 + Cache Digest + multi_fetch_fragments, I was able to do this:

=render partial: 'groups/group', collection: @results, as: :result, cache: true
And `groups/group` partial can support dynamic partial names, like this:
=render partial: "#{group.name}/#{group.name}", locals: {result: user}

However, after upgrading to Rails 4, I'm getting lots of Couldn't find template for digesting: "#{group.name}/#{group.name}" errors. I also tried:

- # Template Dependency: "#{group.name}/#{group.name}"
=render partial: "#{group.name}/#{group.name}", locals: {result: user}

But that's not working. Is this still supported?

Hi ! Thanks for this awesome gem !

I noticed it's not compatible with Tire's collections (the ElasticSearch DSL). For example, if I request a collection of items from tire, then render this collection's partials with cache activated it will work at first. But once I reload the page I get:

NoMethodError: undefined method `delete_if' for #<Tire::Results::Collection:0x007ff3b7845fa0>

This is because cached items are removed from the collection in render_collection_with_multi_fetch_cache using the delete method from ActiveRecords. It doesn't work with Tire's collections since they don't implement this method. However, Tire's collections support Enumerable so it's easy to add the delete method :

module Tire
  module Results
    class Collection
      def delete item
        @results = @results.reject {|i| i == item}
      end
    end
  end
end

I'm not sure if this is a Tire incompatibility or a multi_fetch_fragments one but has you mentioned, in an other issue, that using delete is pretty dangerous, I though it might be useful to use an other technique. But I'm new with your gem so maybe I'm totally wrong :)