This message is to announce the release of version 1.2.0 of the KML Export extension. Although the extension was online for almost a month already, it wasn't announced due to the lack of user documentation.
KML Export is an extension that generates KML files for Google Earth from content in article pages. Users add templates to article pages with geographic coordinates (placemarks) of the subject on the article; the extension provides a special page that scans the articles that contains the placemarks and generates a single KML file, with links leading back to the wiki.
http://www.mediawiki.org/wiki/Extension:KML_Export
hi all,
I'm trying to install the new version of mediawiki ( 1.9.3 ) on my host. However i get the following error message.
Creating job table...Query "CREATE TABLE `job` ( job_id int(9) unsigned NOT NULL auto_increment, job_cmd varchar(255) NOT NULL default '', job_namespace int NOT NULL, job_title varchar(255) binary NOT NULL, job_params blob NOT NULL, PRIMARY KEY job_id (job_id), KEY (job_cmd, job_namespace, job_title) ) TYPE=InnoDB " failed with error code "Specified key was too long; max key length is 1024 bytes (h41mysql1.secureserver.net)".
any idea why this is??
thanks, AJ
-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160
I'm trying to install the new version of mediawiki ( 1.9.3 ) on my host. However i get the following error message.
Creating job table...Query "CREATE TABLE `job` (
...
) TYPE=InnoDB " failed with error code "Specified key was too long; max key length is 1024 bytes
MySQL has a bug in which it counts bytes, not characters, when calculating the key length. Thus, something that works fine in a single-byte-per-character character set suddenly fails when you switch to a multi-byte character set such as utf-8.
One solution (besides abandoning utf-8 or MySQL) is to redefine the index in question to use smaller values. A quick google search found this example:
PRIMARY KEY job_id (job_id), KEY (job_cmd (160), job_namespace, job_title (160))
HTH, - -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200704160927 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
Much appreciate this Greg... will see if I can implement this somehow.
- AJ
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Greg Sabino Mullane Sent: Monday, April 16, 2007 7:02 PM To: mediawiki-l@lists.wikimedia.org Subject: Re: [Mediawiki-l] SQL error..
* PGP Signed by an unknown key
I'm trying to install the new version of mediawiki ( 1.9.3 ) on my host. However i get the following error message.
Creating job table...Query "CREATE TABLE `job` (
...
) TYPE=InnoDB " failed with error code "Specified key was too long; max key length is 1024 bytes
MySQL has a bug in which it counts bytes, not characters, when calculating the key length. Thus, something that works fine in a single-byte-per-character character set suddenly fails when you switch to a multi-byte character set such as utf-8.
One solution (besides abandoning utf-8 or MySQL) is to redefine the index in question to use smaller values. A quick google search found this example:
PRIMARY KEY job_id (job_id), KEY (job_cmd (160), job_namespace, job_title (160))
HTH, -- Greg Sabino Mullane greg@turnstep.com PGP Key: 0x14964AC8 200704160927 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
* Unknown Key * 0x14964AC8(L)
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/mediawiki-l
MySQL has a bug in which it counts bytes, not characters, when calculating the key length.
Computers have a _bug_ too, where they count bytes, not characters, well... everywhere.
Thus, something that works fine in a single-byte-per-character character set suddenly fails when you switch to a multi-byte character set such as utf-8.
The limit doesn't exist with new MySQL versions in MyISAM and old versions in InnoDB. If you're getting that error, there's huge chance you have InnoDB disabled.
One solution (besides abandoning utf-8 or MySQL) is to redefine the index in question to use smaller values. A quick google search found this example:
Or use InnoDB. Or use fresh MySQL version.
Was planning on trying with 5.0 to see if this issue resolves itself.. currently using 4.1
- AJ
-----Original Message----- From: mediawiki-l-bounces@lists.wikimedia.org [mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Domas Mituzas Sent: Tuesday, April 17, 2007 2:22 PM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] SQL error..
MySQL has a bug in which it counts bytes, not characters, when calculating the key length.
Computers have a _bug_ too, where they count bytes, not characters, well... everywhere.
Thus, something that works fine in a single-byte-per-character character set suddenly fails when you switch to a multi-byte character set such as utf-8.
The limit doesn't exist with new MySQL versions in MyISAM and old versions in InnoDB. If you're getting that error, there's huge chance you have InnoDB disabled.
One solution (besides abandoning utf-8 or MySQL) is to redefine the index in question to use smaller values. A quick google search found this example:
Or use InnoDB. Or use fresh MySQL version.
On 16/04/07, Greg Sabino Mullane greg@turnstep.com wrote:
MySQL has a bug in which it counts bytes, not characters, when calculating the key length. Thus, something that works fine in a single-byte-per-character character set suddenly fails when you switch to a multi-byte character set such as utf-8.
It's not particularly fair to consider it a bug. Sure, it's a pain in the ass that MySQL's UTF-8 support is very much lacking, but it's not exactly an undocumented behaviour.
Rob Church
mediawiki-l@lists.wikimedia.org