Last modified: 2011-04-04 21:32:40 UTC
When MySQL is configured with sql-mode="NO_ENGINE_SUBSTITUTION" and skip-innodb in the MySQL configuration file (my.cnf), i.e. InnoDB is disabled and an attempt to use InnoDB will result in an error message, MediaWiki's desire to use InnoDB tables will fail during installation: * Creating tables... using MySQL 3/4 table defs...Query "CREATE TABLE mw_user ( user_id int(5) unsigned NOT NULL auto_increment, user_name varchar(255) binary NOT NULL default '', user_real_name varchar(255) binary NOT NULL default '', user_password tinyblob NOT NULL default '', user_newpassword tinyblob NOT NULL default '', user_email tinytext NOT NULL default '', user_options blob NOT NULL default '', user_touched char(14) binary NOT NULL default '', user_token char(32) binary NOT NULL default '', user_email_authenticated CHAR(14) BINARY, user_email_token CHAR(32) BINARY, user_email_token_expires CHAR(14) BINARY, PRIMARY KEY user_id (user_id), UNIQUE INDEX user_name (user_name), INDEX (user_email_token) ) TYPE=InnoDB" failed with error code "The 'InnoDB' feature is disabled; you need MySQL built with 'InnoDB' to have it working". My suggestion would be that MediaWiki should check whether InnoDB is available (SHOW VARIABLES LIKE 'have_innodb'; should not return DISABLED) and/or the SQL mode (SHOW VARIABLES LIKE 'sql_mode'; should not contain NO_ENGINE_SUBSTITUTION), and possibly attempt to set its preference using dynamic system variables for the session (SET SESSION table_type='InnoDB';), see http://dev.mysql.com/doc/refman/5.0/en/using-system-variables.html, instead of always specifying TYPE=InnoDB in its SQL scripts. Best regards, Björn
MediaWiki relies upon being able to use InnoDB for all the major tables (page, revision, and text at least need decent transaction support), decent length indexes and table space. We're not going to stop specifying a storage engine when we want to use it.
with the forthcoming Falcon storage engine it might make sense to have this be less static; but i don't think MyISAM will ever work well.
Should check whether the new installer code in 1.10 resolves this issue.
Should be fixed with r52672, we now check to make sure the engines are enabled.
