Last modified: 2006-12-22 17:56:23 UTC
Setting up MediaWiki 1.8-svn with MySQL 5.0.22 on Windows server 2003 fails creating tables in the database. Return value: "#1089 - Incorrect sub part key; the used key part isn't a string, the used length is longer than the key part, or the storage engine doesn't support unique sub keys" I traced this back to the creation of the table 'ipblocks', and more specifically the following line in phase3/maintenance/mysql5/tables.sql: UNIQUE INDEX ipb_address (ipb_address(255), ipb_user, ipb_auto, ipb_anon_only), Changing it to the following creates the table and all /appears/ to be fine. As I'm no expert on this matter, I have no idea of the consequences of this change. UNIQUE INDEX ipb_address (ipb_address, ipb_user, ipb_auto, ipb_anon_only), This change was introduced on 2006-07-10 in SVN version 15482 by tstarling. SVN diff attached.
Created attachment 2125 [details] Patch to fix (?)
I can reproduce this with MySQL 5.0.24a on Debian Linux and MediaWiki r16701 when selecting "Experimental MySQL 4.1/5.0 UTF-8" during setup. The patch posted in #1 works for me but as far as I´m not sure for side effects I will not commit it.
Not the exact same error message, but this could probably be marked as a duplicate of bug #1322.
This is not the same as bug #1322. The patch is correct, and I cannot se how it can have any side effects. UNIQUE INDEX ipb_address (ipb_address(255), ipb_user, ipb_auto, ipb_anon_only), means create a unique multiple-column index called ipb_address which consists of the first 255 characters of the ipb_address column and all bytes from ibp_user, ibp_auto and ibp_anon_only. UNIQUE INDEX ipb_address (ipb_address, ipb_user, ipb_auto, ipb_anon_only), means excactly the same, except use all characters of ipb_address. It is meaningless to use the first 255 characters of ibp_address, because it is defined to have only 40. http://www.mediawiki.org/wiki/Project:Support_desk#HELP.21 suggests changing it to ipb_address(40) but, because that will use all the 40 characters, that is the same as without the (40). I suggest this patch is included as soon as possible.
*** Bug 7642 has been marked as a duplicate of this bug. ***
The column ipb_address is now a tinyblob, not a varchar(40). And presumably the reason for 255 is that it can hold a username, which is defined as varchar(255). Still looks like the same issue as #1322 to me.
(In reply to comment #6) > The column ipb_address is now a tinyblob, not a varchar(40). And presumably the > reason for 255 is that it can hold a username, which is defined as varchar(255). As far as I can see, it is still a varchar(40), referring to http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/mysql5/tables.sql?view=co Please correct me if I'm wrong. > Still looks like the same issue as #1322 to me. I should have explained why this is different from bug #1322. They are both related to creating indexes, but bug #1322 concerns exceeding the maximum length of an index. This bug is about referring to the 255 first bytes of a 40-byte variable.
Looks like whoever made the change from varchar(40) to tinyblob forgot to change the MySQL 5 schema file. I've fixed that, removed the default values so strict mode doesn't die, and changed the TYPE= to ENGINE= to suppress warnings. (Judging by docs that's safe on MySQL 4.1.2 and higher, and presumably all 5.0 releases...?) Fixed in r17492
*** Bug 8353 has been marked as a duplicate of this bug. ***
