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

Martin Kutschker masi-no at spam-typo3.org
Wed Oct 29 11:46:55 CET 2008


Ernesto Baschny [cron IT] schrieb:
> Martin Kutschker wrote: on 28.10.2008 23:18:
> 
>>> 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.
> 
> I think it also works like this. Start by doing a:
> 
> DROP PRIMARY KEY;
> 
> then continue "as usual". The current installer is already DROP PRIMARY
> KEY, but only in the "Changing fields" which is done after "Adding fields".
> 
> We "just" need to change it to be done before doing anything to the
> table. And of course this can only be done if the primary key wasn't an
> "auto_increment" before, because in this case we cannot simply drop the
> primary key (the field has to be changed to "non-auto-increment" first).

I think this is complicated as the installer does all it's stuff on a
per-field basis. But the index stuff must be done on a per-table basis.

That's why I think it's a waste of time to rewrite the installer if we
can use a new table. There is absolutely no point in using the old one
as it has been changed completely.

Masi


More information about the TYPO3-team-core mailing list