Last modified: 2014-08-03 20:28:57 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 T12512, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10512 - Separate logging.log_params into a new table
Separate logging.log_params into a new table
Product: MediaWiki
Classification: Unclassified
Database (Other open bugs)
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
: schema-change
Depends on:
Blocks: code_quality 8731 10545
  Show dependency treegraph
Reported: 2007-07-09 14:14 UTC by Aryeh Gregor (not reading bugmail, please e-mail directly)
Modified: 2014-08-03 20:28 UTC (History)
8 users (show)

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


Description Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-09 14:14:25 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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-15 02:21:29 UTC
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?)
Comment 2 Tyler Romeo 2012-06-18 16:34:32 UTC
Is there still interest in this? Because I might be willing to work on it.
Comment 3 Nemo 2013-10-07 11:07:18 UTC
(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.
Comment 4 Aaron Halfaker 2013-12-19 17:51:53 UTC
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.
Comment 5 Nathan Larson 2014-07-31 17:57:16 UTC
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.
Comment 6 Aaron Schulz 2014-07-31 18:02:59 UTC
Just noting...there is a log_search table.
Comment 7 Nathan Larson 2014-08-01 20:28:21 UTC
(In reply to Aaron Schulz from comment #6)
> Just noting...there is a log_search table.

WONTFIX, then?
Comment 8 Tyler Romeo 2014-08-01 20:31:46 UTC
(In reply to Nathan Larson from comment #7)
> WONTFIX, then?

Well, more like WORKSFORME.

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