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

[Bjoern Pedersen]

Am 24.02.2011 08:28, schrieb Ernesto Baschny [cron IT]:
>>
>> 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

I will see what I can do about that. I am not sure if usesExpireField is
a good option name. I think 'dbLayoutVersion' or something like that is
better, as it allows for further upgrades without the need for yet
another option.

v3 is attached.


An alternative idea I had was the following (but that probably should
get implemented later on):
The cache tables are not defined in the sql-files anymore, but created
dynamically by the caching framework. probably with some flag stored
somewhere, so that the check for correct tables gets easier. But that is
something where I do not have enough insight how to handle it the best
way yet. It probably means to have support for that in dbal as well,
then cache tables can be created optimally (without remapping) on other
engines.

Björn
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 17693_v3.patch
Type: text/x-patch
Size: 10708 bytes
Desc: not available
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20110224/043877ce/attachment.bin>