Hi.
I'm trying the following setup: - Windows XP SP2 - MediaWiki 1.4beta6 - Apache 2.0.52 - MySQL 4.1.9 - PHP 5.0.3
So far it's been a rough ride. I had to change the default charset of MySQL from utf-8 to latin1; otherwise I got asorted errors during setup; basically MySQL complained that the cl_sortkey index for the categorylinks table was more than 1024 bytes long. After I tweaked maintenance/tables.sql to get pass that, the build script created the database and the tables all right, and crashed just afterwards, but only when using a table prefix.
Anyway, setting "default-character-set=latin1" in my.ini cured all that, and I've got a working (and very nice) MediaWiki installation.
But now I'm getting a weird error. I create a page (in this case, User:Juanma/monobook.css, but I don't think that's relevant), I delete it, and when clicking on the "deletion log" link (Special:Log/delete) or on "View or restore 1 delete edits" (Special:Undelete/User:Juanma/monobook.css) , I get the following error dump:
------------ error starts here ------------- A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:
SELECT log_type, log_action, log_timestamp, log_user, user_name, log_namespace, log_title, cur_id, log_comment, log_params FROM `user`, `logging` LEFT OUTER JOIN `cur` ON log_namespace=cur_namespace AND log_title=cur_title WHERE user_id=log_user AND log_type='delete' AND log_namespace=2 AND log_title='Juanma/monobook.css' ORDER BY log_timestamp DESC LIMIT 0,50
from within function "". MySQL returned error "1267: Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (latin1_bin,IMPLICIT) for operation '=' (localhost)". ------------ error ends here -------------
I'm really puzzled by the "ltin1_swedish_ci", because my local, if anything, would be Spanish...
Any ideas?
Juanma Barranquero wrote:
Anyway, setting "default-character-set=latin1" in my.ini cured all that, and I've got a working (and very nice) MediaWiki installation.
A warning: if you use mysqldump to back up, be sure to specify the --charset=latin1 option! Otherwise it will try to convert your data from Latin-1 (which is probably really UTF-8 data) into UTF-8, and then back again on import.
This conversion is actually lossy, because four code points in the Windows-1252 encoding (what it really uses for latin1) are undefined; these byte values are used in UTF-8, so they are unrecoverably corrupted.
But now I'm getting a weird error. I create a page (in this case, User:Juanma/monobook.css, but I don't think that's relevant), I delete it, and when clicking on the "deletion log" link (Special:Log/delete) or on "View or restore 1 delete edits" (Special:Undelete/User:Juanma/monobook.css) , I get the following error dump:
This is bug 1057: http://bugzilla.wikimedia.org/show_bug.cgi?id=1057
Try the patch I posted there and please report whether it solves the problem or not (I don't have a MySQL 4.1 test box set up at the moment).
I'm really puzzled by the "ltin1_swedish_ci", because my local, if anything, would be Spanish...
Ah, but MySQL AB is based in Sweden. ;)
The issue of character set configuration in MySQL is a long, sad story and unfortunately the transition to the more or less sensible support in the new 4.1 & 5.0 is going to be ugly as you have seen already.
-- brion vibber (brion @ pobox.com)
On Sun, 06 Feb 2005 17:05:23 -0800, Brion Vibber brion@pobox.com wrote:
This is bug 1057: http://bugzilla.wikimedia.org/show_bug.cgi?id=1057
I should've taken a look at the bug database. Sorry for the noise.
Try the patch I posted there and please report whether it solves the problem or not (I don't have a MySQL 4.1 test box set up at the moment).
The patch doesn't apply cleanly (as you yourself noted on the comment #6), but I've patched maintenance/tables.sql (because I suspect I'll redo the installation quite a few times more), then I've modified the table by hand and it works fine. Thanks!
Ah, but MySQL AB is based in Sweden. ;)
Oh, how did I forget that? :)
The issue of character set configuration in MySQL is a long, sad story and unfortunately the transition to the more or less sensible support in the new 4.1 & 5.0 is going to be ugly as you have seen already.
No problem. I'm glad to help in the testing. I'm installing MediaWiki for my own, personal use, so it's easy to just backup everything and try the cutting edge, even if it really cuts sometimes :)
(I forgot to answer the first part of your message)
On Sun, 06 Feb 2005 17:05:23 -0800, Brion Vibber brion@pobox.com wrote:
A warning: if you use mysqldump to back up, be sure to specify the --charset=latin1 option! Otherwise it will try to convert your data from Latin-1 (which is probably really UTF-8 data) into UTF-8, and then back again on import.
This conversion is actually lossy, because four code points in the Windows-1252 encoding (what it really uses for latin1) are undefined; these byte values are used in UTF-8, so they are unrecoverably corrupted.
What I would really like is to use "default-character-set=utf8". Any idea why MySQL complains that
KEY cl_sortkey(cl_to,cl_sortkey(128))
is longer than 1024 bytes?
Juanma Barranquero wrote:
What I would really like is to use "default-character-set=utf8". Any idea why MySQL complains that
KEY cl_sortkey(cl_to,cl_sortkey(128))
is longer than 1024 bytes?
I'm not sure offhand how MySQL stores these things in utf8 mode, but note that cl_sortkey is set to length 255, and (255+128)*4 > 1024.
The maximum byte length of a legal UTF-8 character is 4 bytes (limited to the 21-bit Unicode range), or it may be storing in UTF-32 which uses a fixed 32 bits per character.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
I'm not sure offhand how MySQL stores these things in utf8 mode, but note that cl_sortkey is set to length 255, and (255+128)*4 > 1024.
I meant cl_to obviously.</brain>
-- brion vibber (brion @ pobox.com)
On Sun, 06 Feb 2005 18:29:58 -0800, Brion Vibber brion@pobox.com wrote:
I'm not sure offhand how MySQL stores these things in utf8 mode, but note that [cl_to] is set to length 255, and (255+128)*4 > 1024.
Well then, would be any problem with MediaWiki if I defined the key as
KEY cl_sortkey(cl_to(128),cl_sortkey(128))
?
Juanma Barranquero wrote:
On Sun, 06 Feb 2005 18:29:58 -0800, Brion Vibber brion@pobox.com wrote:
I'm not sure offhand how MySQL stores these things in utf8 mode, but note that [cl_to] is set to length 255, and (255+128)*4 > 1024.
Well then, would be any problem with MediaWiki if I defined the key as
KEY cl_sortkey(cl_to(128),cl_sortkey(128))
Assuming it lets you define it that way, AFAIK that should work fine.
-- brion vibber (brion @ pobox.com)
On Mon, 07 Feb 2005 01:43:26 -0800, Brion Vibber brion@pobox.com wrote:
Assuming it lets you define it that way, AFAIK that should work fine.
Yes, it does (let me, I mean). It's one of the first things I tried.
OK, I'm gonna experiment with default-character-set=utf8 and the shortened key (and your patch for the other problem).
mediawiki-l@lists.wikimedia.org