Last modified: 2014-09-20 03:45:53 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 70999 - log_params isn't always serialized
log_params isn't always serialized
Status: NEW
Product: MediaWiki
Classification: Unclassified
Logging (Other open bugs)
1.24rc
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 71044
Blocks: code_quality
  Show dependency treegraph
 
Reported: 2014-09-18 14:13 UTC by Nathan Larson
Modified: 2014-09-20 03:45 UTC (History)
5 users (show)

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


Attachments

Description Nathan Larson 2014-09-18 14:13:12 UTC
Sometimes log_params isn't serialized. If keys aren't specified, I would think this would make it harder sometimes to tell at a glance what the data represents. If keys are specified, though, then one needs to extract the data using, e.g., substr().

Three examples I notice are changing visibility of revisions and log events; merging histories; and blocking users (for more details, see [[mw:Manual:Log actions]]).

When you change visibility of a revision, the raw text inserted into log_params is, e.g.:

revision
7
ofield=0
nfield=4

Likewise, merging histories generates, e.g.:

Bar
20140916175747

Blocking a user is the same way; something like the following gets inserted:

3 days
nocreate
Comment 1 Nathan Larson 2014-09-18 14:21:04 UTC
Is this a bug or a feature? Is it desired that sometimes log_params be easily human readable?
Comment 2 Bawolff (Brian Wolff) 2014-09-18 18:37:51 UTC
Its a historical thing.

Once upon a time, fields for log_params were separated by a newline. Then it got changed to being json blob (And possibly there's a couple php serialized blobs in there too, not sure). However not all log types got changed to the new format.

Anyone creating a new log type should use the json serialization. Old log types should be moved to use the the new json format for new entries. (And eventually when that is done, if someone is really board they could create a maintenance script to change old log entries.)
Comment 3 db [inactive,noenotif] 2014-09-18 18:57:38 UTC
json? php serialized is the current format
Comment 4 Bawolff (Brian Wolff) 2014-09-18 19:06:20 UTC
(In reply to db from comment #3)
> json? php serialized is the current format

Whoops, my mistake.

Also block log appears to use csv.

Suffice it to say, log_params is a bit of a mess.
Comment 5 Nathan Larson 2014-09-18 20:32:35 UTC
Page protection events also insert into log_params unserialized content like this:

‎[edit=autoconfirmed] (indefinite)‎[move=autoconfirmed] (indefinite)
Comment 6 Umherirrender 2014-09-19 19:11:59 UTC
Following patches already exists:

- Gerrit change #151683 - Migrate merge log to new log system
- Gerrit change #151701 - Migrate import log to new log system
- Gerrit change #152003 - Migrate block log to new log system
- Gerrit change #152156 - Migrate protect log to new log system
- Gerrit change #152161 - Use new log system when create log entry for revision delete

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


Navigation
Links