[TYPO3-core] RFC: Bug #11903: Use separate tables for tags in the caching framework

[Oliver Hader]

FYI: Committed this as follow-up to SVN Trunk (rev. 6095)

olly


Oliver Hader schrieb:
> Hi again,
> 
> Oliver Hader schrieb:
>> Hi Masi,
>>
>> Martin Kutschker schrieb:
>>> For the SQL Server (and Oracle) I haven't found a way to get the job done in a single (nested)
>>> statement. So have to use two statements:
>>>
>>> DELETE FROM table2
>>>  WHERE id IN
>>>   (SELECT table1.id
>>>    FROM table1 JOIN table2 ON (table1.id=table2.id)
>>>    WHERE table1.column1=value)
>>> DELETE FROM table1
>>>  WHERE table1.column1=value
>>>
>>> But after writing this I wonder if the JOIN is really needed. What exactly is it that the caching
>>> framework is trying to do?
>> The tags are stored in the table "[cache]_tags" and select from that
>> table that has an identifier that is equal in the table "[cache]". The
>> caching framework tries to remove from both tables at once - thus,
>> clearing the tag references and the cached content.
>>
>> Since there it seems that there is no common way to create these queries
>> it would be fine to use two DELETE queries with accordant subqueries.
>> It's important that selects are fast (using separate tags instead of
>> full table scan with LIKE "%tag%"), deletes could be a bit slower...
>>
>> Then we would have something like this:
>>
>> $TYPO3_DB->exec_DELETEquery(
>>   'cache',
>>   'identifier IN (' .
>>       $TYPO3_DB->SELECTquery(
>>         'identifier',
>>         'cache_tags',
>>         'tag = ' . $tag
>>       ) .
>>     ')'
>> );
>> $TYPO3_DB->exec_DELETEquery(
>>   'cache_tags',
>>   'tag = ' . $tag
>> );
>>
>> What do you think?
> 
> With a patch it would bee the following one...
> I'd be happy if some could test this also with DBAL. Thanks in advance!
> 
> olly
-- 
Oliver Hader
TYPO3 Release Manager 4.3