Last modified: 2014-03-11 19:49:40 UTC
MediaWiki is using 14 char field as binary or varbinary or data type timestamp. Please clean this up, by using only one data type for all of them. tables.sql contains a sentence about this: -- The MySQL table backend for MediaWiki currently uses -- 14-character BINARY or VARBINARY fields to store timestamps. -- The format is YYYYMMDDHHMMSS, which is derived from the -- text format of MySQL's TIMESTAMP fields. -- -- Historically TIMESTAMP fields were used, but abandoned -- in early 2002 after a lot of trouble with the fields -- auto-updating. Following fields are timestamp: user_newpass_time binary(14), user_touched binary(14) NOT NULL default '', user_email_authenticated binary(14), user_email_token_expires binary(14), user_registration binary(14), user_editcount int user_last_timestamp varbinary(14) NULL default NULL page_touched binary(14) NOT NULL default '', rev_timestamp binary(14) NOT NULL default '', ar_timestamp binary(14) NOT NULL default '', cl_timestamp timestamp NOT NULL, ipb_timestamp binary(14) NOT NULL default '', ipb_expiry varbinary(14) NOT NULL default '', img_timestamp varbinary(14) NOT NULL default '', oi_timestamp binary(14) NOT NULL default '', fa_deleted_timestamp binary(14) default '', fa_timestamp binary(14) default '', us_timestamp varbinary(14) NOT NULL, rc_timestamp varbinary(14) NOT NULL default '', rc_cur_time varbinary(14) NOT NULL default '', wl_notificationtimestamp varbinary(14) exptime datetime tc_time binary(14) NOT NULL log_timestamp binary(14) NOT NULL default '19700101000000', job_timestamp varbinary(14) NULL default NULL, qci_timestamp binary(14) NOT NULL default '19700101000000' pr_expiry varbinary(14) NULL, pt_timestamp binary(14) NOT NULL, pt_expiry varbinary(14) NOT NULL default '', mr_timestamp binary(14) NOT NULL
I am willing to work on this. As I understand, all the above mentioned columns need to altered to timestamp data type of mysql with give constraints and default values(if any). Have I covered it all or is there anything else to do here ?
I have some questions regarding this bug. 1. user_editcount int --> Is this really meant to be changed to timestamp? 2. user_last_timestamp --> no such column exists in user table.(Using mediawiki 1.23)
(In reply to comment #2) > 2. user_last_timestamp --> no such column exists in user table.(Using > mediawiki 1.23) Wrong table? https://www.mediawiki.org/wiki/Manual:User_newtalk_table
(In reply to comment #3) > (In reply to comment #2) > > 2. user_last_timestamp --> no such column exists in user table.(Using > > mediawiki 1.23) > > Wrong table? https://www.mediawiki.org/wiki/Manual:User_newtalk_table Thanks ! But don't you think this table has conflicting column prefix? (Similar to User table) (In reply to comment #0) > exptime datetime I dint understand this line. Could you explain this?
Change 110949 had a related patch set uploaded by Gerrit Patch Uploader: Add cleanTimeStampFields.php https://gerrit.wikimedia.org/r/110949
user_editcount is wrong here, sorry for that. user_last_timestamp is part of user_newtalk, this column has a wrong prefix exptime is part of the objectcache table You have to call the sql from the updaters. You can found the updaters in includes/installer.
(In reply to db from comment #6) > user_last_timestamp is part of user_newtalk, this column has a wrong prefix Done > exptime is part of the objectcache table Done > You have to call the sql from the updaters. You can found the updaters in > includes/installer. There is no good documentation of installers/updaters, though I have a added a function to call applyPatch() in MysqlUpdater.php Anything else to be done?
