TYPO3 Core

I think this bug is related to 0017221 and the fix http://forge.typo3.org/projects/typo3v4-core/repository/revisions/10323/diff/trunk/typo3/sysext/dbal/class.ux_t3lib_db.php.

This only seems to affect DBAL

Argh! Found the bug, in some rare cases, the [0] was needed...

May I kindly ask you to test again the whole (both bugs)?

I just tested your patch with some cases in the install tool:

TRUNCATE TABLE tx_mwimagemap_area; -> no error

ALTER TABLE tx_mwimagemap_map ADD name tinytext NOT NULL; -> no error

ALTER TABLE tx_openid_assoc_store DROP KEY assoc_handle; -> no error, but command is shown again after execution
ALTER TABLE tx_openid_assoc_store ADD KEY assoc_handle (assoc_handle(8)); -> no error, but command is shown again after execution
ALTER TABLE tx_mwimagemap_area CHANGE id id int(11) auto_increment; -> no error
ALTER TABLE tx_mwimagemap_area DROP PRIMARY KEY; -> no error
ALTER TABLE tx_mwimagemap_area ADD PRIMARY KEY (id); -> error: Incorrect table definition; there can be only one auto column and it must be defined as a key

CREATE TABLE tx_mwimagemap_point ( id int(11) NOT NULL auto_increment, aid int(11) NOT NULL default '0', num int(11) NOT NULL default '0', x int(11) NOT NULL default '0', y int(11) NOT NULL default '0', PRIMARY KEY (id), KEY parent (aid) ); -> no error

ALTER TABLE tx_mwimagemap_point_wrong_name RENAME zzz_deleted_tx_mwimagemap_point_wrong_name; -> no error

DROP TABLE zzz_deleted_tx_mwimagemap_point_wrong_name; -> no error

ALTER TABLE tt_content CHANGE tx_mwimagemap zzz_deleted_tx_mwimagemap varchar(255) NOT NULL default ''; -> no error

ALTER TABLE tx_mwimagemap_area RENAME zzz_deleted_tx_mwimagemap_area; -> no error
ALTER TABLE tx_mwimagemap_bcolors RENAME zzz_deleted_tx_mwimagemap_bcolors; -> no error
ALTER TABLE tx_mwimagemap_map RENAME zzz_deleted_tx_mwimagemap_map; -> no error
ALTER TABLE tx_mwimagemap_point RENAME zzz_deleted_tx_mwimagemap_point; -> no error

ALTER TABLE tt_content DROP zzz_deleted_tx_mwimagemap; -> no error

DROP TABLE zzz_deleted_tx_mwimagemap_area; -> no error
DROP TABLE zzz_deleted_tx_mwimagemap_bcolors; -> no error
DROP TABLE zzz_deleted_tx_mwimagemap_map; -> no error
DROP TABLE zzz_deleted_tx_mwimagemap_point; -> no error

At least, there is no error with "ALTER TABLE tx_openid_assoc_store DROP KEY assoc_handle;" and "DROP TABLE xyz;" is still executed correctly, so I would say it is a big improvement.

The commands "ALTER TABLE tx_openid_assoc_store DROP KEY assoc_handle;" and "ALTER TABLE tx_openid_assoc_store ADD KEY assoc_handle (assoc_handle(8));" are executed again and again, but I think this is an other bug.

Yes, I'll commit that but don't know yet whether I'll will reintegrate this for 4.5.0.

Regarding the other points, one has to know that admin query handling is not completely supported when using DBAL although I agree it would great to support this correctly.

Committed to:

- DBAL trunk (rev. 42650)
- DBAL_1-2 (rev. 42651)
- DBAL_1-1 (rev. 42652)
- DBAL_1-0 (rev. 42653)

dbal has been automatically installed in a fresh installation of TYPO3 4.5 around beta 3. It think either this should be disabled for TYPO3 4.5 or your fix should be committed before releasing TYPO3 4.5.0.

Fix will be part of TYPO 4.5.1, there was no time left for 4.5.0.