Memory cache storage + (cache_classes = false) = Weirdness

If not, could you please post a test case or something ?

Thanks.

It happens with default settings when using Rails.cache

It may be hard to generate a test case since the problem spans both

activesupport and actionpack but I'll try.

--

David Dollar

ddollar@gmail.com

On Jul 17, 2008, at 8:33 PM, Lighthouse

wrote:

Or just paste me the relevant controller/action code from a rails app. Doesn't have to be a test case in Rails test suite.

Thanks.

Information about reproducing the failure is here:

http://pastie.org/236503

Not sure why this is marked invalid. This behavior is clearly still happening in edge. David Dollar stated the problem clearly above, but I'll try again to make the case...

Given the following conditions, common to a dev environment:

• config.cache_classes = false
• config.action_controller.perform_caching = false
• (:memory_store selected by default)

If you attempt to use Rails.cache.fetch in your application, like this:

def index
  @authors = Rails.cache.fetch(:authors) { Author.find(:all) }
end

You will get errors after the first request, either create_time_zone_conversion... or stack level too deep errors (depending on the complexity of your app). These are caused by the combination of Rails.cache caching + cache_classes = false.

My impression is that when perform_caching = false, caching should not actually be performed, and cache.read should return nil. This is not the case, as David Dollar points out above.

There are two problems here: 1. perform_caching = false performs caching, which causes problems if cache_classes is off 2. The case of perform_caching = true but cache_classes = false

It seems we could solve 1. without yet solving 2. In #785 Ryan Bates pointed this out, but the thread was then distracted by the (2) issue.

Many other tickets (#785, #1290, #1339) talk around this issue but seem to get distracted by the class continuity/caching issue. It's certainly a frustrating issue for anyone trying to add "Rails.cache.fetch"-style caching in the development environment.

darn formatting. attaching rest of last comment below.

You will get errors after the first request, either create_time_zone_conversion... or stack level too deep errors (depending on the complexity of your app). These are caused by the combination of Rails.cache caching + cache_classes = false.

My impression is that when perform_caching = false, caching should not actually be performed, and cache.read should return nil. This is not the case, as David Dollar points out above.

There are two problems here: 1. perform_caching = false performs caching, which causes problems if cache_classes is off 2. The case of perform_caching = true but cache_classes = false

It seems we could solve 1. without yet solving 2. In #785 Ryan Bates pointed this out, but the thread was then distracted by the (2) issue.

Many other tickets (#785, #1290, #1339) talk around this issue but seem to get distracted by the class continuity/caching issue. It's certainly a frustrating issue for anyone trying to add "Rails.cache.fetch"-style caching in the development environment.

For anyone that happens to run across this ticket later:

If you use

@authors = cache(:authors) { Author.find(:all) }

the problem goes away.

Thanks David for posting that work around. I can confirm that it works, even with memcached parameters like :expires_in.

For example you can convert this:

@region = Rails.cache.fetch(current_subdomain, :expires_in=>1.week) do
  Region.find_by_subdomain(current_subdomain)
end

to this:

@region = cache(current_subdomain, :expires_in=>1.week) do
  Region.find_by_subdomain(current_subdomain)
end

And it will start working again.

This is a pretty big problem and I agree with David Reese, I don't think it should be marked invalid.

Automatic cleanup of spam.

louis vuitton watches