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

Martin Kutschker masi-no at spam-typo3.org
Sat Sep 26 18:32:58 CEST 2009


Oliver Hader schrieb:
> Hi Steffen,
> 
> Steffen Kamper schrieb:
>> Hi olly,
>>
>> following notes:
>> * unit tests doesn't work, 6 failures in testsuite
> 
> Ok, I fixed them to work with again... however, they are not complete.
> 
>> While testing, the writing works as expected.
>> Clearing cache does the clearing, but i get a MySQL error:
>>
>> ['lastBuiltQuery'] =>
>> 'TRUNCATE '
>> ....
> 
> That happens when no tagsTable is set. And it would have happened if not
> cacheTable was set. It's now checked in the contructor.
> 
> Attached is a new version with these changes:
> * fixed bug in garbage collector concerning removal of entries without tags
> * added contructor check for cacheTable and tagsTable
> * modified unit tests

I know that the patch is in but yet a -1 from me. Why? Because the patch sneaks in a new feature of
t3lib_db. This should have been a separate RFC. The reason is that the new feature
DELETEmultipleTablesQuery() isn't DBAL save.

This surprises me as I have attached many notes in the bug tracker concerning other database
systems.  I suggest to use two different WHERE clauses: one for the JOIN and one for WHERE clause.

This could have been BTW added to the existing DELETE function:

DELETEquery($table,$where,$tableRef='',$whereJoin='')

This allows for an SQL syntax like this:

DELETE titleauthor
FROM titleauthor INNER JOIN titles
   ON titleauthor.title_id = titles.title_id
WHERE titles.title LIKE '%computers%'

BTW, where is the note that the DBAL team is informed and will (have to provide) a follow-up to this
patch for DBAL?

Masi


More information about the TYPO3-team-core mailing list