Going the same route as T163562, we'd need a separate table that references logging and includes a hexadecimal representation of the IP address. That way we could query for ranges at Special:Log.
For revision, the new table ip_changes was introduced with: https://gerrit.wikimedia.org/r/#/c/370946/ (T156318)
I'm creating this task to get some input from DBAs on whether this is really feasible. Thanks!
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T309999 Convert Special:CheckUserLog to use Special:Log | |||
| Open | None | T310000 Make Special:Log capable of holding the checkuser logs | |||
| Open | None | T146628 Add IP range support to [[Special:Log]] | |||
| Open | None | T187579 Create ip_logging table to query for logged actions by IP ranges |
Wouldn't this not work for the intended usecase of T146628 as that's asking for the target of the block log entry, not the user associated with the log entry?
For the block target case, I wonder if the log_search table could be reused for that purpose.
Ah, yes you are right. The way that works always makes my head hurt. ip_logging should still happen as described, I think, but personally I'm more interested in working on block logs for IP ranges.
What we need here I think is a hex representation of log_title, right (assuming we're doing it similar to T163562)? You think log_search may work as-is, or do we need some schema changes?
It would depend on how important having the ipc_timestamp in the index actually is (since log_search doesn't have that. OTOH if there actually is a performance boost, that may be useful for other log_search usecases). Otherwise its a pretty similar setup to the ip_changes table and actually in many ways is meant for a pretty similar use case (except log_search usually assumes the number of results will be very small).