[TYPO3-core] RFC #17693 performace of cachingframework: alternative dbbackend

[Ernesto Baschny [cron IT]]

Bjoern Pedersen schrieb am 23.02.2011 15:34:
> Am 23.02.2011 14:18, schrieb Ernesto Baschny [cron IT]:
>> Hi,
>>
>> why is speed only an "alternative"? Why would anyone use a "slow
>> alternative"? Any drawbacks your implementation has? Why not implement
>> the speed improvements in the original db_backend? After all, we can
>> change the fields of that table on a minor release (4.6), right?
>>
>> Cheers,
>> Ernesto
>>
> 
> That's what the patch more or less does:
> 1) Introduce new class
> 2) change the core caches to new db layout
> 3) use the new class as default for the core.
> 
> Actually I see now that I have to change cache_hash as well.
> v2 is attached.
> 
> The problem is, that extensions (e.g. tt_news) also provide a setup for
> the cachingframework and supply the necessary tables. These extensions
> would break, if we just change the current class.

Ok, understood! The creation of the caching tables is *not* an API but
has to be done individually by each extensions.

Doing a diff between your implementation and the original dbbackend
reveals very little places which needed the change.

So I would suggest to add a new option to be passed to the dbbackend
when creating a cache ('usesExpireField = TRUE'), which tells the engine
if there is a "lifetime" or a "expires" field (you just need to have a
method called "setUsesExpireField($value)" for this to be handled by the
abstract class).

The dbbackend could then by default use the old scheme (backwards
compatibility), and use the new scheme if passed the option. Maybe even
deprecate the use of caches without this option in future.

That would be easier to maintain (a single dbbackend) and less confusing.

Cheers,
Ernesto