Fragment cache not generating the proper cache key

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.

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'

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.

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.

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

I will provide a patch soon.

Attached is patch.