#387 Cache Digests

So that's what 37signals calls Russian Doll Caching?

Would there be any gotchas when doing this with sensitive links that show up or remain hidden depending if a user is an admin or not?

I'm wondering what the purpose of caching an individual task is? It seems as though caching the project view may be sufficient.

I understand the benefit of caching an individual task is that when a project is re-rendered (after a task changes), most tasks will still be cached. But does rendering a task really take that long?

I think the answer to my question lies around how we avoid hitting the database when using fragment caching. I haven't fully thought it through, though.

I don't understand the purpose of this gem at all.

Templates don't (or, at least, shouldn't) change in production, so there are no changes to detect.

Templates do change in development, however this gem requires extra code (explicit partial and collection arguments to render) and developer behavior changes (frequent server restarts).

I've wondered for years why there isn't better (any?) support for testing caching. Wouldn't it be better to have that than to jump through these hoops to test caching in development mode?

Can someone tell me how this helps? Isnt the controller being called on each request where the heavy lifting is done anyway? (DB calls etc)

What to force cache to expire? for example when the list of items are updated?

So how would you cache json? I think I am missing something obvious.

I had a problem using fragment caching when calling the partial in response to javascript i.e. in index.js.erb and using <%= j render @collection %>

I was getting a response, but the javascript to append the response to the page just didn't fire

In order to formulate the proper cache key for some template so that we can check Memcached, does that not require 1+ DB calls (more for nested templates that use some db objects) to fetch the updated_at value on every request?

If so, doesn't this/these mandatory call(s) somewhat offset the performance benefits a bit?

If not, is it implied that cache_digests gem creates static HTML files specific for every call and somehow tag them w/ specific ETags (though this method yields no benefit for users viewing the page the first time)?

There should be noted, that this gem isn't aware of I18n. Because of this you should always write something like

<% cache [I18n.locale, @post] do %>
  <%= t(:post_created_at) %> <%= @post.created_at %>
<% end %>

in multilingual applications or write a helper for this. And there is no plans to support I18n in future. More info.

Is there a way to use this for pages that contain mostly static content, that is only updated whenever the app is updated?

I have some static pages (tutorial, help, contact, about, etc.) that use embedded ruby for for some things, but should otherwise be cached.

Hey Everyone!
I have a few very basic questions about cache digests in rails 4.0

• Do I need to include gem 'cache_digests" in Gemfile for rails 4.0 project?
  I didn't find a cache_digests gem in my project's rvm gemset neither did I put gem 'cache_digests" in my Gemfile. However <% cache xxx do %> actually worked. It wrote to cache and read from it like
  Read fragment views/pets/67-20130627183100171326000/1e699c80fb4b885994ecf5d1b8e61933 (0.1ms)

• There is no cache_digests:nested_dependencies and cache_digests:dependencies tasks if I didn't include gem 'cache_digests" in Gemfile? Is that right?

Any helper's appreciated!

Will these two interfere if m is the same instance but it is used in different partials?

#in _detailed.html.erb
<% cache m do %>
 ... Detailed view...
<% end %>

and then

#in _row.html.erb
<% cache m do %>
 ... row in the list...
<% end %>

V