Rails Ruby on Rails → 2.3.9

Comments and changes to this ticket

• 

  Neeraj Singh June 11th, 2010 @ 03:21 AM

  I tested with rails 2.3.8. Here is my code.

  ActionController::Base.cache_store = :file_store, "#{RAILS_ROOT}/tmp/cache"
  

  <% cache(['hello', User.first]) do %>
    My name is <%= User.first.name %>
  <% end %>
  

  When I visit the page in production mode then cache is generated at

  rails_root/tmp/cache/views/hello/users

  and the file name is

  1-20100611015342.cache

  I am not sure what would be the cache key in 2.3.5 but the result I got looks ok to me.

• You flagged this item as spam.
  

  Brad Forsyth June 11th, 2010 @ 08:48 PM

  In rails 2.3.5 the cache key for this example would be:

  views/hello/users/1-20100611015342

  The log should show 'Cached fragment miss: views/hello/users/1-20100611015342'

• 

  Neeraj Singh June 11th, 2010 @ 09:59 PM

  In my application this is what I get.

  Cached fragment exists?: views/hello/users/1-20100611015731 (0.1ms)
  Cached fragment hit: hello#<User:0x10365c080> (0.5ms)
  

  Now the question is why in one case I see fully expanded key and not in the other case. Answer is below.

  def read_fragment
    self.class.benchmark "Cached fragment hit: #{key}" do
      key = fragment_cache_key(key)
      result = cache_store.read(key, options)
      result.respond_to?(:html_safe) ? result.html_safe : result
    end
  end
  
  def fragment_exist?(key, options = nil)
    key = fragment_cache_key(key)
    self.class.benchmark "Cached fragment exists?: #{key}" do
      cache_store.exist?(key, options)
    end
  end
  

  calling fragment_cache_key could be potentially expensive. So it's okay to leave the code as it is.

• You flagged this item as spam.
  

  Brad Forsyth June 13th, 2010 @ 03:52 PM

  I am not following this logic. The fragment_cache_key is called anyway, it should be called before the benchmark call so that the log clearly shows what key is being used. This is the way it worked previously and I see no advantage nor usefulness to the existing benchmark message.

• 

  Neeraj Singh June 13th, 2010 @ 04:27 PM

  @Brad You are right. Not sure what I was thinking.

  I will provide a patch soon.

• 

  Neeraj Singh June 13th, 2010 @ 05:26 PM

  Attached is patch.

  • 4827_fix_against_2-3-stable.diff 1 KB
• 

  Neeraj Singh June 13th, 2010 @ 05:29 PM

  • Tag changed from “rails 2.3.8” to “rails 2.3.8, patch”
• 

  Neeraj Singh June 13th, 2010 @ 09:53 PM

  • Assigned user set to “José Valim”
• 

  José Valim June 15th, 2010 @ 12:07 PM

  • Milestone cleared.
  • State changed from “new” to “open”
• 

  José Valim June 20th, 2010 @ 11:27 AM

  • Milestone set to “2.3.9”

  Neeraj, thanks for the patch once again! Could you please check if the issue exists in Rails master as well?

• 

  Repository June 23rd, 2010 @ 08:17 AM

  • State changed from “open” to “resolved”

  (from [cc53229378665869fa94170079e0acd3e91d432a]) Fragment cache not generating the proper cache key in log

  [#4827 state:resolved]

  Signed-off-by: José Valim jose.valim@gmail.com
  http://github.com/rails/rails/commit/cc53229378665869fa94170079e0ac...