Add caching system to Views

I've ported this to the DRUPAL-6--3 branch as per merlinofchaos' request. There are a number of hitches, though, that make things tricky. Queries and raw results in particular are very difficult to cache using the new plugin caching mechanism. I've manged to implement rudimentary output caching, but I'm not sure that it will work with any filters or arguments that use contextual information (the currently logged in user, the current date, etc).

Further updates as events warrant.

In the light of day, there are still some thorny problems that need figuring out.

1. Caching of results and output requires first generating the unique aspects of the particular view instance -- essentially, the query that will be run. We can then use that as a key to look up/store the rendered results. Unfortunately, extraction of context (like exposed filter data and arguments) is done deep within the display handler code, and so far I haven't found an easy way to let it get that far, then bail out and use cached output.
2. Similarly, caching queries is promising but it appears that generating a query results in a LOT of properties on the view and display being modified. IE, a $query object is created, but lots of random flags and props get flipped in the process, and unless they're all examined and set explicitly when the cache is retrieved the view fails.

Those are the two biggies I'm looking at right now. The existing views_plugin_cache_time.inc implementation is very dumb -- it just uses the view name, the display ID, and a hash of $_GET to generate its key. That means it can generate a key very early in the views building process, but it only works for page displays and also ignores defaulted arguments and context-sensitive filters like 'author is current user'.

Work continues.

Woo! After chatting with Earl for a while and poking around, I stepped back from trying to cache the queries and focused on output caching. It's definitely a bit easier to work with -- the attached version of the patch includes ONLY output caching implementation, but it reduces a page with the example 'frontpage' view from 107 queries to 34. It currently spits out a 'Cached output used' message via dsm(), and thus will choke if you don't have devel module installed. Further testing to follow....

Here's a cleaned up version of the patch that uses vpr() instead of dsm() for better compatability. I still need to address cache invalidation; right now old data is never cleared out. We should probably clear anything related to a given view or display whenever it's validated. But it's definitely ready for testing at this point.

Now both result AND rendered output caching are working, including paged views.

The *_time cache implementation allows users to set a lifespan independently for results and rendered output -- depending on the output style, there can be problems caching the output so it's nice to be able to turn that off while still getting the result caching.

Next up will be cache invalidation so the tables get cleared out automatically when saving views, etc. Right now, though, it's a perfectly usable patch and can probably be used for some benchmarking.

...And here's a version that ignores caching when the view is being previewed, flushes the cache for a given view whenever it's saved, and properly clears out old cache data when cache plugins are changed.

I'm doing to say that it's starting to hit 'needs review' rather than 'needs work' -- it might not be perfect but it's now fully functional, and doesn't have any major areas of scary wrongness that I'm aware of.

And here's the actual patch.

Whoops. Looks like the notes got lost for that one -- the latest version of the patch properly handles clearing out the cache when the 'Clear cache' button is pressed on the Performance page, or in Devel module. In addition, it properly stores JS, CSS, and HEAD additions made by output styles that use them. Carousels and AJAX pagers now cache properly. Huzzah!

Here's a re-rolled version of the patch for Views 2.x, as well. The patches applied cleanly to that branch with on tweak in $views::execute(), where the logic had been dramatically simplified. It just required wrapping a larger chunk of code in the caching, since it hadn't been pulled into the query class yet.

Tested with exposed filters, ajax paging, and CSS/JS. w00t.

or you could just use the current version of views(dev :) ), i think they are both included there.

The caching feature is included in Views 2.6 -- no need to grab the bleeding edge. Just the cutting edge. ;-)