This project is archived and is in readonly mode.
Memory cache storage + (cache_classes = false) = Weirdness
Reported by David Dollar | July 17th, 2008 @ 04:52 AM | in 2.x
Patch included:
creates a 'Development' cache storage that changes behavior based on the cache_classes setting
When cache_classes is set to false, much weirdness happens by keeping instances of objects in memory and then wiping/reloading their class definitions out from underneath them. This patch creates a "Development" store that is used by default in the development environment that forces cache misses when cache_classes = false
Comments and changes to this ticket
-
Pratik July 18th, 2008 @ 01:33 AM
- State changed from new to invalid
- Assigned user set to Pratik
This would only happen if perform_caching is set to true in development mode. Right ?
-
David Dollar July 18th, 2008 @ 02:15 AM
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
On Jul 17, 2008, at 8:33 PM, Lighthouse
wrote:
-
Pratik July 18th, 2008 @ 02:24 AM
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.
-
David Reese November 11th, 2008 @ 09:20 PM
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...
orstack 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, andcache.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 ofperform_caching = true
butcache_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.
-
David Reese November 11th, 2008 @ 11:02 PM
darn formatting. attaching rest of last comment below.
You will get errors after the first request, either
create_time_zone_conversion...
orstack 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, andcache.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 ofperform_caching = true
butcache_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.
-
David Dollar March 11th, 2009 @ 04:11 AM
For anyone that happens to run across this ticket later:
If you use
@authors = cache(:authors) { Author.find(:all) }
the problem goes away.
-
Brian Armstrong July 25th, 2009 @ 12:45 PM
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.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »
<h2 style="font-size: 14px">Tickets have moved to Github</h2>
The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>
People watching this ticket
Attachments
Referenced by
- 1367 Perform caching=false should not perform caching Tickets #639, #785, and #1290 all dance around this issue...
- 1367 Perform caching=false should not perform caching Tickets #639, #785, and #1290 all dance around this issue...