New cache features: grouping, userdata

Hi, 

just commited a bunch of files with some major changes that should have
given the cache it's final shape. At least I don't have any wishes on it
any more. Before I tell you about the changes: the PEAR DB container is
untested, I don't have PEAR installed, be warned.

+++ Ok, here're the new features:

 - grouping of cache data 
 - every cache data set has an optional userdata field [char(255)]

+++ Why grouping data sets?

Groups give you more control on the cached data. They allow you to add a
certain kind of hierarchie to the cached data. One of the most straight
ahead applications of a userland cache I can think of is to cache the
generation of entire pages. Guess you have webshop with products in 10
categories. The generation of the product presentation pages is based on
a database and it takes you between 2s (20 products) and 10s (200
products) to generate the (template driven) pages dynamically. As this
is quite a long time and your company does not give you more but a slow
Ultra 1 with 167 Mhz, you'd like to cache the generation of the product
lists. Well, the cache gives you what you need. You'll wrap the the
Output Cache around the product list generation and remain everything
else (session, tracker,...) untouched. Astonishing result: 1.5s - 2.5s
for every product list, that's damn close to the times your includes
require (0.8s). Now your customer, a crazy guy, applies every day
changes to the product categorie 1 but not to 2 - 9 which get updated
only once a week. Without a grouping feature you'd have to flush all
your cache content. But by help of the grouping feature you can flush
only the group that belongs to categorie 1.

What is the price of this new feature? Sorry, I had problems metering
it, should be a "slowdown" of less than <5% compared to the old code.

+++ Why a userdata field?

Let's stay in the example of the webshop. Your customer pays a
webdesigner to design the templates. The guy was out for holiday
(snowboarding - what else...) comes back and notices that he need some
money for a new snowboard. He sits down and applies some changes to the
product or even the page templates. One day after your customer call
your chief: hey, man you told that templates are real time stuff, but I
don't see any changes. Well, you got it already your page does not only
depend on the DB content (manual flush()-call) but on the filemtime() of
all templates  used. Without the latest changed to the cache code you'd
do a database request to get the filemtime() of your templates for a
certain cache id, compare the value with the current filemtime()
checksum and flush your cache if neccessary as the expire date does not
really do the trick for you. That means you'd need an extra DB request.
You can save this one with the userdata field in the cache dataset. Save
the original filemtime() checksum in it when you create the cache entry
and compare it on every request. The comparisment is done e.g. in
Output::get()

Speed loss? 
  ~1/100s for the filemtime() checks on my homepage.

Simple example application (homepage): 

content page: 
 http://www.redsys.de/php/show_source.php?file=tech
 (looks somewhat like xml but I use regexps + it[x] template, 
  see http://www.redsys.de/php/show_source.php?file=page)

prepend: 
  http://www.redsys.de/php/show_source.php?file=prepend
append:  
  http://www.redsys.de/php/show_source.php?file=append

cache_output: 
  http://www.redsys.de/php/show_source.php?file=out_cache
  see get() for the trick

+++ XML/XSLT

... of course caching pages is also great for that kind of pages :).


Ulf