Future major features

 
 
Martin Langhoff - Sailing
Re: Feedback requested on new Logging specification
Group DevelopersGroup Particularly helpful Moodlers
To add an example or two.

From a scalability perspective, mdl_log is a big bottleneck. Ot makes sense to log somewhere else, somewhere where we don't have to contend for a lock, no need to maintain indexes, etc.

Options include logging to a file, logging to in-memory tables (all our RDBMSs have some support), splitting the logging into several files or tables (to reduce contention), etc.

All of these options are supplemented by a cronjob or daemon that feeds the data to a database table (where it gets all the benefits of indexes, etc) in a way that is more DB-friendly.

The data in that short-term pool isn't easily query-able. If we put demands on it being readable, then we paint ourselves into a corner...
 
Average of ratings: -
Picture of Petr Skoda
Re: Feedback requested on new Logging specification
Group DevelopersGroup Documentation writersGroup Moodle HQGroup Particularly helpful Moodlers
Hello!

I agree with what you say. The API we are proposing should be suitable for any mechanism of log storage because the reading and writing can be fully independent. Nothing with the exception of reports should be reading the data from log storages, that should imho help when dealing with any delay between writing and reading.
 
Average of ratings: -
Martin Langhoff - Sailing
Re: Feedback requested on new Logging specification
Group DevelopersGroup Particularly helpful Moodlers

Nothing with the exception of reports should be reading the data from log storages

Well, that's the easy case. But we have two cases I know off the top of my head that make this a bit more interesting.

  • "Live logs", which is only useful if it can read the recent logs, so it will need some form of API, or get axed. And I do think it is useful.
  • Recent activity block. Also useful, can perhaps cope with a short delay.
 
Average of ratings: -