[TYPO3-core] RFC #9505: Make the caches in TYPO3 use the new caching framework

Ingo Renner ingo at typo3.org
Wed Oct 29 02:26:26 CET 2008


Martin Kutschker wrote:
> Ernesto Baschny [cron IT] schrieb:
>> Ingo Renner wrote: on 20.10.2008 22:19:
>>
>>>> You change the SQL-definitions of cache_hash and cache_pagesection:
>>>> Executing that in that order will never add the "id" field,
>>> As you figured out yourself this is a known issue with the database
>>> compare in the install tool, but is not related to this patch. We need
>>> to fix this of course before releasing 4.3.0 or even 4.3.0alpha1.
>>> I think Stucki wanted to look into this? @Stucki, do you still plan
>>> doing so?
>> The "UPDATE" problem is quite a blocker in my eyes, but you are right
>> that this is not "your problem" in this patch. But I would like to see
>> the patch to fix that issue of the real soon, maybe even before some
>> release (alpha1), because the side-effect of not updating the cache
>> table will probably be a not-used new caching system, making it hard for
>> folks to test it (or add a note to the alpha1 release to "DROP
>> cache_hash" before upgrading, if there is no time to fix the database
>> compare stuff.
> 
> This is what I had to do to get the table right:
> 
> * clear table - wouldn't work otherwise!
> * add field without auto_increment
> * add key
> * add field with auto_increment
> 
> I don't think that the installer will ever be able to do stuff like that.
> 
>>>> So to overcome that problem, I would like to know if there is a need for
>>>> an "auto_increment" field in a caching table? Isn't that unnecessary
>>>> overhead for something that is ought to be fast?
>>> does auto increment slow things down? didn't know if that is the case...
>> I am sure it "slows down" something, but I cannot imagine that it is
>> noticeable. But as we already have seen two negative side effects
>> (update problem and potential slow-down) of the "id" auto_increment
>> field, and no useful function for that field (?), we might as well drop
>> it. Any reason against it?
> 
> If we don't need it, drop it.

AFAIK we at least need it as a fast index (numeric/autoincrement) 
indexes should be faster than having a string index mysql needs to work 
through.

> To make things easier I think we should simply use new tables. It saves
> us from adding IMHO superfluous stuff to the installer (the change is
> far from being a standard change). As any old will break anyway with the
> new table layout we can simply create a new one and discard the old.

no, why? It's working!

Ingo

-- 
Ingo Renner
TYPO3 Core Developer, Release Manager TYPO3 4.2


More information about the TYPO3-team-core mailing list