https://bugzilla.wikimedia.org/show_bug.cgi?id=25503
Aryeh Gregor <simetrical+wikib...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simetrical+wikib...@gmail.c
| |om
--- Comment #4 from Aryeh Gregor <simetrical+wikib...@gmail.com> 2010-10-13
18:41:46 UTC ---
(In reply to comment #0)
> I am trying to upgrade 1.15.4 to 1.17 trunk, while running update.php I've got
> the following error message:
>
> ...doing rev_id from 59003 to 59202
> ...doing rev_id from 59203 to 59402
> ...doing rev_id from 59403 to 59602
> ...doing rev_id from 59603 to 59802
> rev_len population complete ... 3701 rows changed (0 missing)
> Creating iwlinks table...ok
> ...iwl_prefix_title_from key already set on iwlinks table.
> Adding ul_value field to table updatelog...ok
> Adding iw_api field to table interwiki...ok
> ...iwl_prefix key doesn't exist.
> ...iwl_prefix_from_title key doesn't exist.
> Adding cl_collation field to table categorylinks...A database query syntax
> error has occurred.
> The last attempted database query was:
> "ALTER TABLE `wiki_categorylinks`
> CHANGE COLUMN cl_sortkey cl_sortkey varbinary(255) NOT NULL default '',
> ADD COLUMN cl_sortkey_prefix varchar(255) binary NOT NULL default '',
> ADD COLUMN cl_collation varbinary(32) NOT NULL default '',
> ADD COLUMN cl_type ENUM('page', 'subcat', 'file') NOT NULL default 'page',
> ADD INDEX (cl_collation),
> DROP INDEX cl_sortkey,
> ADD INDEX cl_sortkey (cl_to, cl_type, cl_sortkey, cl_from)
> "
> from within function "DatabaseBase::sourceFile(
> /var/www/wiki/phase3/maintenance/archives/patch-categorylinks-better-collation.sql
> )".
> Database returned error "1071: Specified key was too long; max key length is
> 1000 bytes (localhost)"
Please post the output of "SHOW CREATE TABLE wiki_categorylinks\G". I have a
guess as to how this could happen, but would like to confirm it.
> Should I patch them temporarily and which key limitations would you suggest?
Make the cl_sortkey column (*not* the index) shorter until it works. Offhand,
I'd think
ALTER TABLE wiki_categorylinks CHANGE COLUMN cl_sortkey cl_sortkey
varbinary(230) NOT NULL default '';
should do it, because I'm guessing it's 255*3 = 765 bytes for cl_to in utf8,
one byte for cl_type, four bytes for cl_from, 765 + 1 + 4 = 770, leaving 230
bytes for cl_sortkey. But I'd like that SHOW CREATE TABLE from you to confirm
it.
Ideally, please try different sizes and tell me the biggest that works. My
first guess is 230 should work but 231 shouldn't, but try various sizes and
tell me what you get.
(In reply to comment #2)
> I've changed maintenance/patch-categorylinks-better-collation.sql like this
> (see an attachment) and the problem went away. Is it OK to use cl_sortkey(1)
> in
> cl_sortkey index?
No. That destroys the point of the index, you may as well just drop the index
entirely if you do that. The field itself has to be shortened, not the index.
The index has to cover the whole field to work correctly. (Although if your
wiki is small enough, you might not notice the difference if the index isn't
working.)
> Maybe it would be a good idea for wikimedia to have a myisam-based setup at
> some of it's testing hosts?
This is not related to MyISAM, as far as I know -- it's probably related to the
use of utf8 collation instead of binary.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
