Last modified: 2013-08-30 05:37:01 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T28517, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 26517 - On install - Database returned error 1071: Specified key was too long;
On install - Database returned error 1071: Specified key was too long;
Status: REOPENED
Product: MediaWiki extensions
Classification: Unclassified
LiquidThreads (Other open bugs)
REL1_19-branch
All All
: Normal critical (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-12-31 01:48 UTC by David Foote
Modified: 2013-08-30 05:37 UTC (History)
7 users (show)

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


Attachments

Description David Foote 2010-12-31 01:48:47 UTC
Running MediaWiki 	1.16.0
MySQL 	5.1.50
Collation set to utf8-unicode-ci

Suggestions?

Full error output follows

Creating thread table...A database query syntax error has occurred.
The last attempted database query was:
"CREATE TABLE `thread` (
 thread_id int(8) unsigned NOT NULL auto_increment,
 thread_root int(8) unsigned UNIQUE NOT NULL,
 thread_ancestor int(8) unsigned NOT NULL,
 thread_parent int(8) unsigned NULL,
 thread_summary_page int(8) unsigned NULL,
 thread_subject varchar(255) NULL,
 thread_author_id int unsigned NULL,
 thread_author_name varchar(255) NULL,
 thread_modified char(14) binary NOT NULL default '',
 thread_created char(14) binary NOT NULL default '',
 thread_editedness int(1) NOT NULL default 0,
 thread_article_namespace int NOT NULL,
 thread_article_title varchar(255) binary NOT NULL,
 thread_article_id int(8) unsigned NOT NULL,
 thread_type int(4) unsigned NOT NULL default 0,
 thread_sortkey varchar(255) NOT NULL default '',
 thread_replies int(8) DEFAULT -1,
 thread_signature TINYBLOB NULL,
 PRIMARY KEY thread_id (thread_id),
 UNIQUE INDEX thread_root_page (thread_root),
 INDEX thread_ancestor (thread_ancestor, thread_parent),
 INDEX thread_article_title (thread_article_namespace, thread_article_title, thread_sortkey),
 INDEX thread_article (thread_article_id, thread_sortkey),
 INDEX thread_modified (thread_modified),
 INDEX thread_created (thread_created),
 INDEX thread_summary_page (thread_summary_page),
 INDEX (thread_author_id,thread_author_name),
 INDEX (thread_sortkey)
 ) ENGINE=InnoDB, DEFAULT CHARSET=utf8
"
from within function "DatabaseBase::sourceStream".
Database returned error "1071: Specified key was too long; max key length is 1000 bytes (localhost)"
Comment 1 Sam Reed (reedy) 2010-12-31 05:32:25 UTC
mysql> CREATE TABLE `thread` (
    ->  thread_id int(8) unsigned NOT NULL auto_increment,
    ->  thread_root int(8) unsigned UNIQUE NOT NULL,
    ->  thread_ancestor int(8) unsigned NOT NULL,
    ->  thread_parent int(8) unsigned NULL,
    ->  thread_summary_page int(8) unsigned NULL,
    ->  thread_subject varchar(255) NULL,
    ->  thread_author_id int unsigned NULL,
    ->  thread_author_name varchar(255) NULL,
    ->  thread_modified char(14) binary NOT NULL default '',
    ->  thread_created char(14) binary NOT NULL default '',
    ->  thread_editedness int(1) NOT NULL default 0,
    ->  thread_article_namespace int NOT NULL,
    ->  thread_article_title varchar(255) binary NOT NULL,
    ->  thread_article_id int(8) unsigned NOT NULL,
    ->  thread_type int(4) unsigned NOT NULL default 0,
    ->  thread_sortkey varchar(255) NOT NULL default '',
    ->  thread_replies int(8) DEFAULT -1,
    ->  thread_signature TINYBLOB NULL,
    ->  PRIMARY KEY thread_id (thread_id),
    ->  UNIQUE INDEX thread_root_page (thread_root),
    ->  INDEX thread_ancestor (thread_ancestor, thread_parent),
    ->  INDEX thread_article_title (thread_article_namespace, thread_article_title,
    -> thread_sortkey),
    ->  INDEX thread_article (thread_article_id, thread_sortkey),
    ->  INDEX thread_modified (thread_modified),
    ->  INDEX thread_created (thread_created),
    ->  INDEX thread_summary_page (thread_summary_page),
    ->  INDEX (thread_author_id,thread_author_name),
    ->  INDEX (thread_sortkey)
    ->  ) ENGINE=InnoDB, DEFAULT CHARSET=utf8;
Query OK, 0 rows affected (0.14 sec)

mysql> ^CCtrl-C -- exit!
Aborted
reedy@ubuntu64-esxi:~$ mysql --version
mysql  Ver 14.14 Distrib 5.1.49, for debian-linux-gnu (x86_64) using readline 6.1
reedy@ubuntu64-esxi:~$

WFM...

Seemingly, an "error" with that collation - As per the error... It's as that collation uses multiple bytes per character

mysql> SHOW VARIABLES LIKE '%collation%';
+----------------------+-------------------+
| Variable_name        | Value             |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database   | latin1_swedish_ci |
| collation_server     | latin1_swedish_ci |
+----------------------+-------------------+

is mine (and the toolserver), and that's fine



    ->  INDEX thread_article_title (thread_article_namespace, thread_article_title,
    -> thread_sortkey),

2 fields are 255 chars.. I'm guessing that they're to blame...
Comment 2 Roan Kattouw 2010-12-31 14:26:09 UTC
I thought s/varchar/varbinary/ was the way to "fix" this?
Comment 3 David Foote 2010-12-31 23:30:41 UTC
@Reedy, Changing to a Latin Collation seems to have to effect.  The database charset is Unicode too though, which I need it to be incidentally

@Roan - Not sure what you mean?  Can you explain further
Comment 4 Roan Kattouw 2011-01-01 00:39:09 UTC
(In reply to comment #3)
> @Roan - Not sure what you mean?  Can you explain further
My question was directed to the MySQL experts around here. IIRC changing varchar to varbinary in the table definition was previously used to fix a similar case.
Comment 5 Mark A. Hershberger 2011-01-28 23:33:58 UTC
What problems would changing the s/varchar/varbinary/ introduce?  Is there anyone who has tested this with varbinary?
Comment 6 Andrew Garrett 2011-01-28 23:34:50 UTC
(In reply to comment #5)
> What problems would changing the s/varchar/varbinary/ introduce?  Is there
> anyone who has tested this with varbinary?

Should be fine, but I'm rewriting the LiquidThreads schema as we speak, so it's not necessarily high priority.
Comment 7 Mark A. Hershberger 2011-01-28 23:53:43 UTC
> Should be fine

So is there a reason to retain varbinary instead of varchar? (I ask b/c if your rewrite includes changing varchar to varbinary, I'd like to close this bug.)
Comment 8 Andrew Garrett 2011-01-29 00:00:30 UTC
(In reply to comment #7)
> > Should be fine
> 
> So is there a reason to retain varbinary instead of varchar? (I ask b/c if your
> rewrite includes changing varchar to varbinary, I'd like to close this bug.)

This is confusing. If you mean retaining varchar instead of varbinary, then no, there's no need to keep it as a varchar.
Comment 9 Mark A. Hershberger 2011-01-29 00:52:45 UTC
sorry for the confusion: glad you saw through it :)
Comment 10 Mark A. Hershberger 2011-01-29 00:53:42 UTC
closing as FIXED since Andrew is rewriting and aware of this problem.
Comment 11 contrafibularity 2013-07-04 19:25:28 UTC
Andrew may be aware : ) but nothing was fixed, I'm afraid. See http://www.mediawiki.org/wiki/Thread:Extension_talk:LiquidThreads/Database_error
Comment 12 Jesús Martínez Novo (Ciencia Al Poder) 2013-07-06 09:03:09 UTC
Resetting "assigned to" since that complete rewrite was abandoned AFAIK and Andrew may not be in the project anymore
Comment 13 Nemo 2013-08-30 05:37:01 UTC
This bug is definitely not low priority; however, it's not clear if there is someone willing to work on 1.19 issues for LQT (there is no maintainer so nobody can decide if it's supported or not, sorry).

With what releases this is confirmed to happen?

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


Navigation
Links