[TYPO3-dev] t3lib_cache

[ries van Twisk]

On Jan 18, 2008, at 11:04 AM, Ernesto Baschny [cron IT] wrote:

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

The extension is responsible to register each record (list or single)  
that
will appear on a page. So this goes for list aswell as for single (or  
any other 'view').
The extension should know..

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

I have seen complex solutions in TYPO3 that could solves easily ;)

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

I feel that page cache clearing is a core problem (and this is where  
we differ), not a extension problem.
I can see the mess already much like the no_cache() function and
configuration variable which is used totally wrong in many extensions.  
I think
this is exactly what new version of TYPO3 API's needs to prevent.

An extension is only responsible for telling
core what records has been shown on what page and what records have been
modified (if used FE forms like commenting extensions).

When using the list module this can be done using hooks.

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

We all want the same and that is an API for cache handling,
I just don't like an API that an extension can (mis) use for cache  
clearing
functions which is similar as the no_cache function already available.


When looking at this page : http://wiki.typo3.org/index.php/Functions_for_t3lib_cache

this function clearPageCache(..) is the same is the no_cache () cache  
function already available (IMHO)


Ries


PS: Please don't do this $where = '1';  but changed it to $where =  
'true';
select * from pages where 1; is invalid SQL 1 is not a boolean value  
and after the where clause SQL needs to evaluate to booleans. SQL is  
not PHP!!!!