Migrating log access in reports

This document is aimed to assist developers in replacing SQL queries to log table in the reports or other plugins.

As new logging system is being introduced in Moodle 2.7, wrting to the log table is called "legacy logging" and still may be supported on some systems. Administrator may set up other logging plugins that can write the data to DB table in the same DB as Moodle, in another DB (SQL or non-SQL), to the file, and so on. By default a logstore_standard plugin is enabled that writes the data in the internal DB table. Moodle core defines several interfaces for reading data from the log storage plugins. Reports have the choice of accessing the active log storage via interface or registering their own observers and storing necessary data themselves.

Using log reader

First, report need to find available log readers.

There are three interfaces defined in core that log storage plugin may implement.

• \core\log\reader - parent for all reader interfaces;
• \core\log\sql_select_reader - has methods to create simple SQL queries to the log table. The table is expected to have columns that correspond to properties of class \core\base\event;
• \core\log\sql_internal_reader - additionally has a method to return the table name which can be used for JOIN queries.

Report decides which type of readers it can work with. Assuming we need a select reader:

$manager = get_log_manager();
$selectreaders = $manager->get_readers(\core\log\sql_select_reader);
if ($selectreaders) {
    $reader = reset($selectreaders);
} else {
    // No available log reader found.
}

The method \core\log\manager::get_readers() returns an associative array of singleton instances of enabled log store plugins implementing the reader interface. When plugin finds the necessary log reader it can query the data from it. Refer to the interfaces for the list of methods they implement.

For the transition period the report might need to access both log storages - the current and legacy, especially if it needs information for a long period of time. Please note that columns and event names are different in the new logging system and legacy log and most likely separate queries will be needed.

Example how to get the legacy log reader (it is often present but not necessary enabled for writing):

$manager = get_log_manager();
$allreaders = $manager->get_readers();
if (isset($allreaders['logstore_legacy'])) {
    $legacyreader = $allreaders['logstore_legacy'];
    if ($legacyreader->is_logging()) {
        // All events continue to be recorded in {log} table.
    } else {
        // The {log} table is kept for storing the old logs only. New events are not written to it and must be taken from another log storage.
    }
} else {
    // You are probably developing for 2.10 and table {log} does not exist any more. Or administrator uninstalled the plugin.
}

Registering observer

Accessing log table on big systems may be slow. Some reports may wish to create their own mini log storages only for necessary rare events and store them for limited time. If developer anticipates the small size of such table and is concerned about the performance, this can be an alternative solution to reading the log table.

In order to implement this plugin must:

• define database table in PLUGINDIR/db/install.xml and also create it in PLUGINDIR/db/upgrade.php
• define event observers in PLUGINDIR/db/events.php and the handling functions themselves, see Events 2
• define cron job that truncates the old entries from the table
• possibly create an upgrade script that migrates the necessary events from the log table into the new plugin table in PLUGINDIR/db/upgrade.php
• re-write the SQL queries inside the plugin to access the new table instead of log