[TYPO3-calendar] Caching: Smart Invalidation?!

[Mario Matzulla]

Hi Stephan,

Am 10.08.11 10:20, schrieb Stephan Helten:
> Hi,
>
> my proposal was only regarding the detail view of one event.
>
> One approach to extend this cache tagging concept is to use tags for months
> and years, too.
>
> If a page is a month view it should tag his cache e.g. with
> "cal_month_201108".
> If it shows a whole year "cal_year_2011" and for days something like
> "cal_day_20110810".
> When creating a new event or modifying it, the start and endtime (etc.) is
> known, so cache tags could be generated, like this:
>
> * cal_year_2011
> * cal_month_201108
> * cal_day_20110810
> * cal_day_20110811
> * cal_day_20110812

sorry, but it is not that easy, because views can have a much wider 
range than it might look at the first glance: for example a day/week 
view can have several months in the sidebar, or a month has "monthOff" 
days (days to complete a week). So I currently don't see a system to 
generate an exact tag for the range :(

We do have a hint though: startPointCorrection and endPointCorrection 
(TS parameters for each view). But imagine an event gets created  for 
one day: 10.08.2011 and we have a start & endPointCorrection of 40 days. 
Than you would have to clear all days and weeks starting 22.06.2011 to 
10.10.2011, the month view of august and the year view 2011.

Maybe we could add 2 timestamp fields (maybe they are already there?) 
instead of using the tag field: starttime and endtime. Than we could 
save timestamps there and clear everything within a given range? Does 
that make sense?

Regards,
Mario

>
> All entries with at least one of these tags would be invalidated.
> Maybe there are some cases where more cache entries are deleted than
> necessary, but I think the granularity was much better than the current one.
>
> regards
>
> Stephan
>
> -----Ursprüngliche Nachricht-----
> Von: typo3-project-calendar-bounces at lists.typo3.org
> [mailto:typo3-project-calendar-bounces at lists.typo3.org] Im Auftrag von
> Thomas Kowtsch
> Gesendet: Montag, 8. August 2011 20:20
> An: typo3-project-calendar at lists.typo3.org
> Betreff: Re: [TYPO3-calendar] Caching: Smart Invalidation?!
>
> Hi Stephan,
>
> On 08.08.2011 07:58, Stephan Helten wrote:
>>> I'll need to take a closer look on how/where the cHashs are actually
>>> calculated. But in any case, there is no out-of-the-box solution for
>>> this problem since there is no Typo3 API for this (tsfe can only delete
>> cache by pid).
>>
>> I think, one could use cache tags and the reg1 field for being compatible
>> with older typo3 verions or disabled caching framework (if support for
> this
>> is necessary).
>
> At least, cal should not fail if one of these constraints fails.
>
> One additional thing we should discuss with Mario is that I'd like to
> see a config switch to turn this on/off.
>
>> When a detailpage is loaded this code could be executed:
>>
>> if (TYPO3_UseCachingFramework) {
>> 	// CachingFramework
>> 	$GLOBALS['TSFE']->addCacheTags(
>> 		array(
>> 			'cal_details_'.intval($calDetailUid)
>> 		)
>> 	);
>> } else {
>> 	// native caching mechanism
>> 	$GLOBALS['TSFE']->page_cache_reg1 = intval($calDetailUid);
>> }
>> In a backend saving hook (processDatamapClass or processCmdmapClass) one
>> could trigger the deletion of cache entries with the same tag when a cal
>> record changes:
>> if (TYPO3_UseCachingFramework) {
>> 	// CachingFramework
>> 	$tags = array(
>> 		'cal_details_'.$calUid
>> 	);
>> 	$pageCache = $GLOBALS['typo3CacheManager']->getCache('cache_pages');
>> 	$pageSectionCache =
>> $GLOBALS['typo3CacheManager']->getCache('cache_pagesection');
>> 	$pageCache->flushByTags($tags);
>> 	$pageSectionCache->flushByTags($tags);
>> } else {
>> 	// native caching mechanism
>> 	// Read pid of tt_products details page from extension configuration
>> 	$confArray =
>> unserialize($GLOBALS['TYPO3_CONF_VARS']['EXT']['extConf'][$this->extKey]);
>> 	$singleViewPid = intval($confArray['PIDitemDisplay']);
>>
>> 	$GLOBALS['TYPO3_DB']->exec_DELETEquery('cache_pages', 'reg1='.$
>> calUid.' AND page_id='.$singleViewPid);
>> }
>
> Mmmmh... two more questions / thoughts:
> - This helps on changing events, but what about new events? Does anyone
> here has an idea how to clear cached pages with the corresponding
> day(s)? (that was my first thought while writing my previous post
> regarding the hash calculation...))
> - We should not forget to implement this also for FE edit. ;-)
>
>> I would do the implementation for the details view cache invalidation like
>> this in an own extension, but I think it would be nice for all cal users.
>> I could build this into cal, if you like?!
>
> "It depends" :-)
> For a fast solution (and maybe even getting some feedback from more
> users), a separate extension in TER would help - we did not even start
> working on v1.5, and 1.4.2 is a bugfix release only.
> On the other hand, it sounds to me as if it would be beneficial for all
> cal users. So, could you give it try and file a feature request in the
> bugtracker [1] and tag it initial for v1.5?
>
> Your help on this topic could really help to speed up cal in daily
> business :-)
>
> Regards,
> Thomas
> [1] http://svn.webempoweredchurch.org/projects/calendar/issues
> _______________________________________________
> TYPO3-project-calendar mailing list
> TYPO3-project-calendar at lists.typo3.org
> http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-project-calendar
>