Last modified: 2013-10-23 18:17:00 UTC
In my database I have no Primary Key in the table users. This makes it impossible to edit this table e.g. using the MySQL Workbench. You get the error message "table data is not editable because there is no primary key defined for the table." Maybe the updater should to care that the Primary Key is set and set it, if it is missing. I use MediaWiki 1.18.
Issue is likely due to r5210, user_id was converted to a PRIMARY KEY but a patch was never made.
The problem is also present for a number of other tables as well, for example "cur", "math", "text", "user_rights" or "watchlist".
(In reply to comment #2) > The problem is also present for a number of other tables as well, for example > "cur", "math", "text", "user_rights" or "watchlist". Of course, math is now in an extension
What version was that wiki installed at? Out of interest...
It surely used MW 1.4 and maybe also an earlier version.
Given that the earliest database entry was May 2004 it was probably 1.2 or 1.3
Yes, that is quite likely.
John, as you assigned this to yourself, are you likely to get round to it any time soon? Might be nice to get it in 1.19/1.18.1, finally!
(In reply to comment #7) > Yes, that is quite likely. Any chance you could do a dump of your database schema layout? Gives a slightly nicer working point, rather than a list of old (now somewhat renamed) tables SHOW CREATE TABLE tablename; mysql> show create table user\G *************************** 1. row *************************** Table: user Create Table: CREATE TABLE `user` ( `user_id` int(5) unsigned NOT NULL AUTO_INCREMENT, `user_name` varbinary(255) NOT NULL DEFAULT '', `user_real_name` varbinary(255) NOT NULL DEFAULT '', `user_password` tinyblob NOT NULL, `user_newpassword` tinyblob NOT NULL, `user_email` tinyblob NOT NULL, `user_options` blob NOT NULL, `user_touched` varbinary(14) NOT NULL DEFAULT '', `user_token` varbinary(32) NOT NULL DEFAULT '', `user_email_authenticated` varbinary(14) DEFAULT NULL, `user_email_token` varbinary(32) DEFAULT NULL, `user_email_token_expires` varbinary(14) DEFAULT NULL, `user_registration` varbinary(14) DEFAULT NULL, `user_newpass_time` varbinary(14) DEFAULT NULL, `user_editcount` int(11) DEFAULT NULL, PRIMARY KEY (`user_id`), UNIQUE KEY `user_name` (`user_name`), KEY `user_email_token` (`user_email_token`) ) ENGINE=InnoDB AUTO_INCREMENT=16029390 DEFAULT CHARSET=binary 1 row in set (0.00 sec)
Created attachment 9824 [details] Output of mysqldump --no-data Attached is the DB structure, which I got with mysqldump --nodata Only 19 tables do have a primary key. And I don't know, if these are how they should be).
Just found bug 15441 for note (In reply to comment #0) > It seems that some tables do not have primary keys nor any unique attributes > declared: > > - 7 with MySQL [archive externallinks hitcounter oldimage querycache > querycachetwo user_newtalk]). >
(In reply to comment #10) > Created attachment 9824 [details] > Output of mysqldump --no-data > > Attached is the DB structure, which I got with > mysqldump --nodata > > Only 19 tables do have a primary key. And I don't know, if these are how they > should be). FYI (In reply to comment #2) > No PK (but has unique index): > categorylinks > change_tag > imagelinks > interwiki > iwlinks > langlinks > log_search > module_deps > msg_resource > msg_resource_links > page_props > oagelinks > protected_titles > querycache_info > searchindex > site_stats > tag_summary > templatelinks > transcache > user_former_groups > user_groups > > No PK or unique index: > archive > externallinks > hitcounter > l10n_cache > oldimage > querycache > querycachetwo > user_newtalk In your DB install, all these tables aren't needed (trackback is newly gone). Cleaned up in r108502 'blobs', // 1.4 'brokenlinks', // 1.4 'cur', // 1.4 'ip_blocks_old', // Temporary in 1.6 'links', // 1.4 'linkscc', // 1.4 'old', // 1.4 'trackback', // 1.19 'user_rights', // 1.5 'validate', // 1.6 Your text table is very out of date (numerous extra fields and indexes). I've added code in r108504 to tidy this up
After a lot of reading today, I'm going to mark this as a duplicate of bug 15441 There are unique keys in place where there should be primary keys... The only difference I can see of a Primary Key vs a Unique Key, is a PK CANNOT be null Therefore they should be pretty much identical... *** This bug has been marked as a duplicate of bug 15441 ***
