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