This project is archived and is in readonly mode.
read_fragment should cache itself for a request to avoid race conditions
Reported by Michael Vastola | May 5th, 2010 @ 12:14 AM
Hi,
I'm reposting this bug from the old Rails trac site since I can't
sign up to comment on it (http://dev.rubyonrails.org/ticket/8408)
and the post seems to have been abandoned. The original bug post is
as follows:
A good paradigm to support would be to allow in your controller:
unless read_fragment(blah)
#do something to set instance variables from the database here
end
Then you only do the tough database access from your controller if there is no cache for the relevant items (this would be less necessary if there were support for pagination in the models or at least in views, though there are still cases where it would apply). The problem is that the cache can be expired between the controller method and the view method.
So, let's say that @result is the result of a large database query.
MyController.rb:
unless read_fragment(blah)
@result = do_large_calc
end
myview.rhtml: cache(blah) do
#do something with @result
end
The problem is that if someone expires your cache fragment between the controller and the view (which I have happen a LOT), then you wind up using @result even though it is not set up.
What needs to happen is that read_fragment is cached in memory during a request, so that all future cache requests to that fragment within the same request returns the same result.
I would like to second this bug report and confirm the bug still exists in ActionPack 2.3.5 (the bug was originally reported in version 1.2.3). I think it would be great if the bug could be fixed in this way or if there were some other workaround.
Thanks a ton,
Mike
Comments and changes to this ticket
-
Michael Vastola May 5th, 2010 @ 12:15 AM
- Tag changed from “cache read_fragment actionpack” to “actionpack, cache, read_fragment”
-
Santiago Pastorino February 2nd, 2011 @ 05:02 PM
- State changed from “new” to “open”
This issue has been automatically marked as stale because it has not been commented on for at least three months.
The resources of the Rails core team are limited, and so we are asking for your help. If you can still reproduce this error on the 3-0-stable branch or on master, please reply with all of the information you have about it and add "[state:open]" to your comment. This will reopen the ticket for review. Likewise, if you feel that this is a very important feature for Rails to include, please reply with your explanation so we can consider it.
Thank you for all your contributions, and we hope you will understand this step to focus our efforts where they are most helpful.
-
Santiago Pastorino February 2nd, 2011 @ 05:02 PM
- State changed from “open” to “stale”
-
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>
Michael Vastola