Last modified: 2014-08-03 20:28:57 UTC
Currently out logging table has fields log_user, log_namespace, log_title, and log_params, which have to be squeezed to fit all possible things you might want to log, or left blank if irrelevant. This is not particularly ideal, and results in several issues with loss of data, sorting, and searching. I would like to deprecate those columns and make a new table, such as: CREATE TABLE `logging_params` ( -- Foreign key to logging table `lp_id` int(10) NOT NULL default '', -- The type of information being logged. Specific to the type of log, e.g., -- blocking may have a targetid parameter. Any given log entry may have -- multiples of these, (lp_id, lp_type) is NOT unique. This allows things -- like multiple protecttype entries for a protection log entry instead of -- a single comma-delimited field. `lp_type` varbinary(10) NOT NULL default '', -- The value of this particular (lp_id, lp_type) pair. This is NULL just -- because some of these fields might be boolean, so may as well use NULL/ -- NOT NULL as the distinguishing characteristic. `lp_value` varchar(255) NULL, KEY (`lp_id`, `lp_type`, `lp_value`) ) Note: since each log id should correspond to probably two to ten rows in the logging_params table, I'm not sure there's any point in have the key extend to the rather large text fields.
Note that this does not apply solely to replacing log_params, but potentially also to replacing log_user, log_namespace, and log_title. Of course, the conservative thing to do would be to leave those be for now even if this is done. (Would there be any efficiency difference?)
Is there still interest in this? Because I might be willing to work on it.
(In reply to comment #2) > Is there still interest in this? Because I might be willing to work on it. Tyler, I think there is. Changes in 1.19 were undocumented and broke a number of things; we need log_params to be less obscure. https://www.mediawiki.org/wiki/Manual:Logging_table#log_params
FWIW, I'm very interested in this bug. I do a lot of work analyzing the history of actions in Wikipedia and this change would make my work easier. For example, right now I am working out historical page moves by parsing revision comments rather than using the logging table because it is easier to search than log_params.
I suggest having an lp_id primary key and an lp_logid. Fixing this bug will be particularly useful, I think, for helping fix bug 60090 in an elegant way, since there could be hundreds of revisions involved in any given import.
Just noting...there is a log_search table.
(In reply to Aaron Schulz from comment #6) > Just noting...there is a log_search table. WONTFIX, then?
(In reply to Nathan Larson from comment #7) > WONTFIX, then? Well, more like WORKSFORME.
