Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Migrating log access in reports: Difference between revisions

From MoodleDocs
Line 12: Line 12:
== Registering observer ==
== 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 usually for a short period of 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.
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 [[Event_2#Event_observers|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

Revision as of 07:05, 6 March 2014

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

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;
  • \core\log\sql_internal_reader - additionally has a method to return the table name which can be used for JOIN queries.

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