2.4. Log File Export

As mentioned in the What's New chapter, the log file export now looks a bit different to 6.2. The logging data is now longer available in its own pre-customized log file (course_admin_log, course_statistics_log etc) but has to be extracted from the logging table directly at user's request. The log file export must take care of limiting the data which is presented to the user (e.g. anonymizing any user information, only providing non-sensitive data etc). It also takes into account, whether a logging action is of type resourceadminaction or not and exports one or the other.

In order to support huge logging tables with large amounts of exported data, there is an implementation of the log export which uses stored procedures of MySQL. If you run into scalability issues with the log file export you might want to consider using stored procedures as well. The functionality is encapsulated in the

org.olat.course.statistic.ExportManager

which is configured in the following spring file:

olat3/webapp/WEB-INF/src/serviceconfig/org/olat/course/statistic/_spring/olatdefaultconfig.xml

There are currently three implementations of ICourseLogExporter (of which one is to be configured in the above mentioned olatdefaultconfig.xml:

SimpleLogExporter: This one is uses Hibernate, is therefore the most generic one but has the downside of not being very performant.
SQLLogExporter: This one is configured with some SQL (therefore DB dependent) which it executes directly, bypassing any Hibernate. This allows logging data to be extracted from a slave DB (should the data not be available on the master DB)
UZHStoredProcedureLogExporter: This is a rather specific implementation used at UZH where a stored procedure is used directly in the slave database for performance reasons.