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

[Ernesto Baschny [cron IT]]

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.

>> 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?

>> Apart from that, do we need to re-use the table names "cache_hash" and
>> "cache_pagesection" if we are changing their definition completely?
>> Maybe those should simply be dropped and some fresh new tables with
>> different names could be created? That would also avoid the problem of
>> older extensions trying to access "reg1" field in cache_hash table etc.
> 
> well, there's never been a clear API anyways and I think it's a little
> late now anyways. Other core devs also gave there ok to break things in
> this case. The advantages completely outweigh the disadvantages I'd say,
> do you agree? Stuff would also break if we'd use new tables...

True. Agreed.

>> Other than that, I did some quick tests, and it seems to be working
>> fine! Thanks for your efford and persistence on that front! ;)
> 
> is that a (/the still needed) +1?

It is difficult to test all remifications. I have tried to read it all,
changes look sensitive. That is what the "alpha" is all about,
especially for such huge features. So go ahead, +1, let's give it a try!

Cheers,
Ernesto