This is a highly useful addition, and I'd be pleased to see a developer that finds the time to implement a brief log fork implementing this. Early agreement for this has been generally seen, at the WT:RFR page http://en.wikipedia.org/wiki/WT:RFR.

Anthony

User:AGK
en.wikipedia.org

Don't expect his to happen, really.

Why do you say that? Is it /unable/ to be done? Is it being refused? Is the situation too controversial at this time?

ayg wrote:

This is totally impractical with the current schema. Scanning a few hundred times as many rows as are needed would probably be common with the enwiki setup, even if you don't allow arbitrary searches of this type. (If you do, you could look for all bureaucrat promotions with a limit of 500 set and force a scan of *all* rights-change rows.) Some new schema would have to be developed, possibly specific to userrights logs but possibly uniform across all logs. The former is messy and problematic in various ways. The latter is cleaner and works better for combined log display, but I'm not sure how it would be best achieved.

One possibility would be to break off log_params into its own 1:N table, theoretically something like logparams (lp_log, lp_key, lp_value) (with lp_log a foreign key into logging.log_id). Then, for instance, for userrights, instead of storing "sysop\nsysop, bureaucrat", we could store two rows like ('previousgroup', 'sysop'), ('newgroup', 'sysop'), ('newgroup', 'bureaucrat').

In practice, for this to be efficient we would need to denormalize substantially, since cross-table indexes aren't possible. To allow efficient retrieval of all rollback additions we would probably need something like (lp_log, lp_type, lp_action, lp_key, lp_value, lp_timestamp, lp_deleted), with all the added fields being carbon copies of the respective logging columns. Finally, redundancy should be added to the rows, so that in the case of user rights, you would add additional keys like 'addedgroup', 'removedgroup'. That would make the desired query something like

SELECT *
FROM loggingparams
JOIN logging ON lp_log = log_id
WHERE lp_type='rights'
AND lp_action='rights'
AND lp_key='addedgroup'
AND lp_value='rollbacks'
AND lp_deleted = 0
ORDER BY lp_timestamp DESC

would be efficient with appropriate indexes ("appropriate" being, I guess, (lp_type, lp_action, lp_deleted, lp_key, lp_value, lp_timestamp) or some similar monstrosity).

Honestly, this would require so much denormalization that it might be best to scrap the entire logging table and add all its fields to the loggingparams table, since the former would contain practically no useful information not already contained in the latter.

Needless to say, all this is fairly complicated. I don't anticipate this getting done unless some dev gets really interested in solving the problem (Werdna seems to be a good suspect for this sort of thing). It would have considerable benefits beyond this, though: it would allow much more flexible log filtering and sorting for *all* log types. Of course domas will hate all the wasted disk space and indexes, too. Anyone have a better idea that would actually work?

mike.lifeguard+bugs wrote:

There is a decent script for this thanks to Splarka. Might be nice to have it in the software, but I won't cry if you kill this bug.

not implementable