[TYPO3-core] RFC: Fix bug #9639: DB Analyzer / Compare Tool can't handle the upgrade of the cache tables

Martin Kutschker masi-no at spam-typo3.org
Wed Nov 12 08:12:02 CET 2008


Steffen Kamper schrieb:
> Hi,
> 
> Martin Kutschker schrieb:
>>
>> Would it technically be sufficient to remove all indices these fields
>> and to drop the autoincrement on uid before performing any other changes
>> to the table?
>>
>> Masi
> 
> this sounds good to me. Important is the order of dropping
> * drop indices
> * alter field having auto_increment
> * drop primary key
> this should help, and the table can be modified in any way.
> 
> I tried what Michael said that you can't create a field with
> auto_increment.
> 
>> 1. The table must be cleared to make sure that the keys are unique.
>> This is no problem for cache_* tables.
>> 2. auto_increment must be set _after_ the primary key was created.
> 
> So i went to table cache_hash filled with records (no truncate)
> and did this:
> ALTER TABLE `cache_hash` ADD `id` INT NOT NULL AUTO_INCREMENT PRIMARY
> KEY FIRST ;
> 
> and it worked without a problem
> 
> So the problem must be in the way how the Compare tool generates the
> SQL-query. I'm not so in the code to make a patch now but may be this
> helps in finding a solution.

I remember that Michael said - and it's the order I remember in the
output - that indices are processed last. Which is ok.

Not ok, is the fact that "unwanted" fields are renamed/removed last.
This has to be moved to the top (at least the renaming). I'm not sure
how indices are handled especially indices on "unwanted" fields. I only
remember that key/index creation appears "randomy" in the add-field
section of the DB analyter. Seems to be a week point.

BTW, I the DB comparison would move away from string (SQL definition) to
property comparison it would work much better. It would cope with ouput
of different Mysql versions and it would also cope with other RDBMS.

Masi


More information about the TYPO3-team-core mailing list