[TYPO3-dev] t3lib_cache

[ries van Twisk]

On Jan 17, 2008, at 10:55 AM, Ernesto Baschny [cron IT] wrote:

> ries van Twisk wrote: on 17.01.2008 14:50:
>
>> 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.....)
>
> Caching is not only dependant on records, so I would not
> delegate that task to core. This will only handle pure "single views"
> where just one record for one extension is shown.

Why only single views?
if a record is changed, then also a list view can be changed, right?

>
>
> Here a bunch of examples:
>
> - list view of news, which displays the latest 5 news in category ABC:
> caching depends on records that are placed in category ABC and not  
> on a
> record in particular
>
> - product teasers that are attached to a certain news record. Maybe  
> two
> are selected at random from all records that are linked to that news
> record for display.
>
> - a news list view with paginator (all cached). The paginator is of
> course dependant on the total number of records that were selected by
> the news extension and not on a particular news uid.
>
> - etc

----

>
>
> The information about which records exactly where rendered during the
> creation of a page might be interesting, but not really the most
> relevant stuff when the extensions needs to decide which pages to
> "obsolete".

I think this is really interesting, because then in BE and/or FE you  
can simply
execute a query to delete all cached pages where record XY is found,
this can be done with one efficient query effectively. I had this idea
one day when I was working at a company where we had many of these
situations. You also could store additional start/end time information  
in
that table to purge pages based on start/end times. This will solve
a other problem...

However, extensions must be ready  and use such an API to make use of  
this.

An API could look like this:

//$row['uid'] is the UID of the record (tt_news record for example).
// registerDisplayObject is part of piBase
// Since it's part of piBase you can get the prefixId  to know what  
extension is responsible

$this -> registerDisplayRecord($row['uid']);

registerDsplayObject will then store in a seperate table the current  
page uid, the prefixid and the record uid.
A table like that could look like this

pageuid integer
recorduid integer
recordprefixid varchar()
starttime integer (taken from the origional record (somehow))
endtime integer (taken from the origional record (somehow))
changed boolean

I don't know how it will work with workspaces!!!!! Never used it,  
never will....

The above will 'know' what pages to delete the cache from based on  
changed records.
in the BE or FE you simply call a other API with the same parameters  
that will tell if a record has been changed or not.
Using a cron you can then purge pages on a x minute interval, or  
during a record update in the BE/FE


Ries