[TYPO3-dev] t3lib_cache

[ries van Twisk]

Just to give you my opinion,

a nice table for the purpose would be nice.
This can solve many problems (fast) for example if you have
data chown (for example news) on multiple pages/branches then there  
should be a method that whenever
a nice item is changed/added... the pages/branches where that news  
item shows up
should beable to get purged from the cache.

Personally i think that typo3 core should handle this and not the  
responsibility of an extension,
and extension could only register records to the caching system so  
core knows where to find what.
(thinking out loud here.....)

Ries

PS: Daniel, your mail address is written down wrong....

On Jan 17, 2008, at 8:00 AM, Daniel Bruessler wrote:

> Hello Ernesto,
>
> yes, varchar is better. The tagging with "tx_testextension_table:5454"
> is a nice idea. But still I find it better to have a M:N ;-)
>
> The current int-value can be used for more than one register! Just by
> multiplication. But that's not reaaaly nice.
> first value: 10^0
> second value: 10^3 or 10^4
>
> Cheers!
> Daniel
>
>> 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