[TYPO3-dev] t3lib_cache

[Ernesto Baschny [cron IT]]

Daniel Bruessler wrote: on 17.01.2008 13:12:
> Hello Steffen,
> 
> yes, sorry :-)
> 
> So what's with these new functions:
> 
> setCacheReg($value, $key='reg1')
> clearCacheByPage ($uid)
> clearCacheByReg ($value, $key='reg1', $pid=0)
> 
> annotation: if $pid=0 the function clearCacheByReg this reg-value is 
> cleared for any page.
> 
> So for the moment it's just possible to have "reg1" or "reg2" as value 
> (is there really a reg2? In the API I just found class-var 
> "page_cache_reg1")

There is no reg2.

And what I was trying to suggest was that we just need one "tagging" 
method for cached pages, and this doesn't need to be just an integer 
(like reg1 currently is).

If we have an indexed varchar, this might be enough (e.g. 
"tx_testextension_table:5454" would identify a cache tagged with this 
table uid entry, so the extension knows where the single-view was 
rendered). With this approach, currently only "one" extension can put 
their information in this reg1 (later "ident" or something). The API for 
it is pretty "dumb", just set $TSFE->page_cache_reg1. Meaning also that 
the "latest called extension" wins.

To overcome that, maybe we could already think about many extensions 
trying to do that. In order not to pollute the current cache_pages with 
more fields, it might be interesting to create a cache_pages_ref table like:

id int(11)  foreign key to cache_pages.id
extkey varchar indexed
ident varchar indexed

So that there is a 1-M relation between cached-pages and "tags" for this 
cache entry. So it is then later easy to locate caches that affect 
certain records. E.g. say we have a page with:

- news single view with uid=666 and
- two product teasers with uid=777 and 888 on the left border (same page)

1) cache_pages contains one rendered page with id=2323
2) cache_pages_ref contains two entries:

2323, tt_news, 666
2323, product_ext, 777
2323, product_ext, 888

Say the extension product_ext knows that 888 product is "obsolet" or 
something has changed or "whatever", it will then be able to find all 
pages that display information about that record and delete all cache 
related to it (here is where t3lib_cache API comes in).

The "ident" varchar might also be used in some other ways other than 
storing the pure uid. Maybe there is a list of uids, maybe there is 
nothing at all, maybe there are keywords like "latest_view". It's up to 
the extensions author to think about how he wants to manage the TYPO3 
page cache.

Cheers,
Ernesto