[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