Manual:Log search table

The log_search table (added in ). Either or both log_search and can be used for storing data about log events. log_search, being indexed, is used for filtering for live queries. RevisionDelete for example uses it to filter log events down to the revision ID (not just page). For example, if revisions 48 and 49 are deleted by log event 29, then there would be two rows created in log_search, with ls_field equal to 'rev_id' for both fields, ls_value equal to 48 for the first field and 49 for the second field, and ls_log_id equal to 29 for both fields. For offline use (e.g. slow analytics), log_params is enough.

The functions used for storing data in log_search are usually ManualLogEntry::setRelations and LogPage::addRelations.

ls_field
The type of ID ('rev_id', 'log_id', 'ipb_id', 'target_author_id'; and according to tables.sql, 'rev timestamp' and 'username'.) Others can be added.

ls_value
The value of the ID (e.g. if ls_field is 'rev_id', then ls_value would contain the rev_id).

ls_log_id
Key to log_id

Schema Summary
DESCRIBE log_search; +---+--+--+-+-+---+ +---+--+--+-+-+---+ +---+--+--+-+-+---+ 3 rows in set (0,10 sec)
 * Field    | Type             | Null | Key | Default | Extra |
 * ls_field | varbinary(32)    | NO   | PRI | NULL    |       |
 * ls_value | varchar(255)     | NO   | PRI | NULL    |       |
 * ls_log_id | int(10) unsigned | NO  | PRI | 0       |       |