[TYPO3-dev] t3lib_cache

[Ernesto Baschny [cron IT]]

ries van Twisk wrote: on 17.01.2008 17:22:

>> 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?

Yes, but which? A list view showing the 5 "latest" news in category ABC. 
How will a single record change affect that cache? What about a *new* 
news record? Will it appear on that page? Depends on its timestamp and 
on the category it is in etc. Maybe a record is updated, it was on 
category XY, now it is also on category ABC. Only the extension itself 
knows where this record might appear. This is what I was trying to 
explain, why it is not so simple for TYPO3 core to know what caches to 
clean on a simple record changes (or on expiration of endtime).

Re-read the examples below please:

>> 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...

For trivial situations this will of course work, but not for most cases, 
which is why we cannot declare this to be the a "caching-clearing and 
start/stop-time problem solution".

> 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

He, if it was that easy, we would have it already. Your proposed table 
is exactly what I was trying to propose, only that your solution is 
based around the assumption that rendered pages are just dependant on 
the status of specific database records and my proposition was based on 
the assumption that it is up to the extension to "know" which records 
affect what parts of the cache.

Try to go through my simple examples above and try to see what this 
means in your proposed solution.

Cheers,
Ernesto