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

[Martin Kutschker]

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.

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

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.

But SOMETHING has to be done. Maybe not for the alpha (even then an
upgrade note would be nice as the change is not so trivial), but
definitively  for the first beta.

Masi