Last modified: 2006-12-22 17:56:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6737 - tables.sql failing for MySQL 5.0.22
tables.sql failing for MySQL 5.0.22
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
1.8.x
All All
: High critical with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 7642 8353 (view as bug list)
Depends on:
Blocks: 3738
  Show dependency treegraph
 
Reported: 2006-07-19 14:38 UTC by Siebrand Mazeland
Modified: 2006-12-22 17:56 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch to fix (?) (555 bytes, patch)
2006-07-19 14:39 UTC, Siebrand Mazeland
Details

Description Siebrand Mazeland 2006-07-19 14:38:47 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.
Comment 1 Siebrand Mazeland 2006-07-19 14:39:16 UTC
Created attachment 2125 [details]
Patch to fix (?)
Comment 2 Jimmy Collins 2006-09-30 10:33:01 UTC
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.
Comment 3 Greg Sabino Mullane 2006-10-02 23:40:50 UTC
Not the exact same error message, but this could probably be marked as a
duplicate of bug #1322.
Comment 4 tiny_green 2006-10-23 00:34:23 UTC
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.
Comment 5 tiny_green 2006-10-23 01:20:28 UTC
*** Bug 7642 has been marked as a duplicate of this bug. ***
Comment 6 Greg Sabino Mullane 2006-11-07 05:11:43 UTC
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.
Comment 7 tiny_green 2006-11-07 17:21:34 UTC
(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.
Comment 8 Brion Vibber 2006-11-08 14:05:23 UTC
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
Comment 9 Brion Vibber 2006-12-22 17:56:23 UTC
*** Bug 8353 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links