|
Martin Burger
|
Wednesday 05 August 2009 2:26:21 am
Hi, I upgraded several eZ publish installations to version 3.10.1. The upgrade path was 3.8.0 -> 3.8.10 -> 3.9.5 -> 3.10.1. In all upgrades, I used the same set of commands to do the actual upgrade (according to the upgrade guides). After upgrading, I checked the database consistency of all sites via Setup -> System Upgrade. While most of the sites don't show any warning, two sites show the same inconsistencies:
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_act_org;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_act_org ( action, is_original );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_action;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_action ( action, id, link );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_par_act_id_lnk;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_par_act_id_lnk ( parent, action, id, link );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_par_lnk_txt;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_par_lnk_txt ( parent, link, text );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_par_txt;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_par_txt ( parent, text );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_text;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_text ( text, id, link );
ALTER TABLE ezurlalias_ml DROP INDEX ezurlalias_ml_text_lang;
ALTER TABLE ezurlalias_ml ADD INDEX ezurlalias_ml_text_lang ( text, lang_mask, parent );
The server runs MySQL version 5.0.32-Debian_7etch10-log. I compared table "ezurlalias_ml" in a consistent and in an inconsistent database, their structure is exactly the same:
CREATE TABLE IF NOT EXISTS `ezurlalias_ml` (
`id` int(11) NOT NULL default '0',
`link` int(11) NOT NULL default '0',
`parent` int(11) NOT NULL default '0',
`lang_mask` int(11) NOT NULL default '0',
`text` longtext collate latin1_german2_ci NOT NULL,
`text_md5` varchar(32) collate latin1_german2_ci NOT NULL default '',
`action` longtext collate latin1_german2_ci NOT NULL,
`action_type` varchar(32) collate latin1_german2_ci NOT NULL default '',
`is_original` int(11) NOT NULL default '0',
`is_alias` int(11) NOT NULL default '0',
`alias_redirects` int(11) NOT NULL default '1',
PRIMARY KEY (`parent`,`text_md5`),
KEY `ezurlalias_ml_text_lang` (`text`(32),`lang_mask`,`parent`),
KEY `ezurlalias_ml_text` (`text`(32),`id`,`link`),
KEY `ezurlalias_ml_action` (`action`(32),`id`,`link`),
KEY `ezurlalias_ml_par_txt` (`parent`,`text`(32)),
KEY `ezurlalias_ml_par_lnk_txt` (`parent`,`link`,`text`(32)),
KEY `ezurlalias_ml_par_act_id_lnk` (`parent`,`action`(32),`id`,`link`),
KEY `ezurlalias_ml_id` (`id`),
KEY `ezurlalias_ml_act_org` (`action`(32),`is_original`),
KEY `ezurlalias_ml_actt_org_al` (`action_type`,`is_original`,`is_alias`),
KEY `ezurlalias_ml_actt` (`action_type`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german2_ci;
Interestingly, all the indexes actually exist in the database schema. However, if I run the queries against the database, MySQL will show an error:
#1170 - BLOB/TEXT column 'action' used in key specification without a key length
Thus, it is not possible to drop and add the indexes. However, at least two question arise: (1) Why do two eZ publish instances complain about the structure above, while the others don't? Although they use the very same structure. (2) Why does eZ publish warn about these inconsistencies at all, although the indexes do exist? I checked the kernel files etc., they are the same. Further, I emptied the inconsistent table "ezurlalias_ml" in one of the two inconsistent databases. However, eZ publish still complains about this table. Thus, the failure should be caused by the structure, and not by the table's content. What could be the cause for these inconsistencies? Or, why does eZ publish believe table "ezurlalias_ml" is inconsistent? Regards Martin Burger
http://www.netbeyond.de/
|