@ Aaron Patterson > I'm not really a fan of this. When I read this code, it's difficult to > understand how ":create" is related to "Post".
Yes, I've not focused too much on the syntax, probably there are a lot of better ways to express the same thing, also it would been better if i've used an example with fragment cache in views. > The other problem is > that if I were to read the file that defines Post, I would not be able > to understand the impact of Post on the entire system. I have a question here: how much expiring cache is supposed to be tight to the model? Is really a good idea to have models or even controllers generally aware of what needs to be expired? Here it's ok to couple caching with model since retrieve the "most recent posts" is a business domain feature: class Post class << self def most_recent_posts Rails.cache.fetch ... end end # ... end using an observer or decorator here is also fine to create a separate layer that adds caching behavior. Sweepers are better when we need to control cache at controller/application logic level (page/action/requests ..). But in this second snippet it's not ok to have the model/controller knowing what needs to be expired since it's something only related to views: # inside Post or PostSweper after_create expire_fragment: "list_of_the_most_recent_posts" --- <%= cache("list_of_the_most_recent_posts") do %> <ul> ... </ul> <% end %> Also, to be more pragmatic, as the application grows we could have a lot of fragments and it could be not so simple to manage them with sweepers as they are. We have to remember what to expire and also to delete expiration code when it is used no more, but also the same fragment can be fetched across multiple views, and so we've to check this with 'grep -R "fragment_key"' ./views' ... growing our apps makes things get too complicated ... not good. So wouldn't this (or something like this) be better? <%= cache("a_fragment", :expire_when => :something_happens) do %> ... <% end %> and just say: "ok, done to cache this part of the page". It would be ok to have a sort of Observer to define the 'something_happens' part. > Can you explain the problem you're trying to solve? Maybe we can work > from there to come up with a better solution. I've probably explained it yet, but sometimes managing the cache expiration can be a mess, i was inspired from this podcast (http://content.newrelic.com/railslab/videos/08-ScalingRails-Memcached-fixed.mp4) by Greg Pollack, in which he uses memcached (with a fixed amount of memory) along with a caching key trick to solve the same problem. These podcasts are a little outdated but i've not found other solutions yet, so I'm trying to generalize this approach using a more explicit way to declare expiration conditions. But it could be useful also to have something similar at a lower level, just a step above Rails.cache. @Andrew Selder > You could probably hook up something similar using > ActiveSupport::Notification and instrumenting the create action in the Posts > controller, or alias_method_chain the create method on Posts to do what you > want. I have to make a premise: actually i was working on a non-RESTful controller (https://github.com/mcasimir/rambler) when i realized that i could have benefit from :expire_when or something similar, probably my initial nuisance with the ordinary way to expire cache is related to that since other times i was fine with it. @ both of you If i'll have some time i could try to make a raw implementation to compare the two approaches and then i will post some consideration - gists that we can review. (maybe using ActiveSupport::Notification or similar would be fine, thanks Andrew) Thanks, Maurizio -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.