Proposal for a complement to Sweepers to expire Rails cache

[mcasimir]

Hi,
I wish to ask you if could be a good idea to introduce in Rails a simple complement to Sweepers that could reduce the effort of expiring cache, something like that:

Rails.cache.fetch("recent_posts", :expires_when => [:create, Post])

The above example could setup a callback to expire "recent_posts" each time that a Post is created.

Sometimes I would like to rely on something like that to expire cache in place of sweepers/observers.

What do you think? There may be downsides with this approach?

[Steve Klabnik]

What's inadequate about this?
http://guides.rubyonrails.org/caching_with_rails.html#sweepers

[Steve Klabnik]

Sigh, I'm an idiot and mis-read your email. Please ignore my last one. :[

[Maurizio Casimirri]

No problem ;)

Il giorno 02/ago/2012, alle ore 01.33, Steve Klabnik ha scritto:

> Sigh, I'm an idiot and mis-read your email. Please ignore my last one. :[
>

> --
> 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 rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>

[Aaron Patterson]

On Wed, Aug 01, 2012 at 04:27:48PM -0700, mcasimir wrote:
> Hi,
> I wish to ask you if could be a good idea to introduce in Rails a simple
> complement to Sweepers that could reduce the effort of expiring cache,
> something like that:
>
> Rails.cache.fetch("recent_posts", :expires_when => [:create, Post])
>
> The above example could setup a callback to expire "recent_posts" each time
> that a Post is created.

I'm not really a fan of this. When I read this code, it's difficult to
understand how ":create" is related to "Post". 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.

> Sometimes I would like to rely on something like that to expire cache in
> place of sweepers/observers.
> What do you think? There may be downsides with this approach?

Can you explain the problem you're trying to solve? Maybe we can work
from there to come up with a better solution.

--
Aaron Patterson
http://tenderlovemaking.com/

[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.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.

To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/9cOxfQkvlu4J.

[Maurizio Casimirri]

@ 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