Rails core - Aug 2012 - Proposal for a complement to Sweepers to expire Rails cache

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?

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

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

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

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

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

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/

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.


On Aug 1, 2012, at 4:27 PM, mcasimir <maurizio.cas@gmail.com> 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.
> 
> 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?
> 
> -- 
> 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.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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