Problem/Motivation
The current AI Logging submodule implementation invented a custom logging solution, with a custom log entity type that uses separate fields to store data, and a Views UI to display it.
Keeping the custom log implementation is not good for several reasons:
- Performance: Storing logs in SQL is good for quick start and local testing, but not good for performance.
- Support: If we keep the current solution, we have to support and manage a lot of logging and displaying logs related code.
- Custom logging: A lot of sites use custom logging to not overload the database with log records and not decrease the logging performance. So they use logging to syslog, files, stdout, custom filtering, aggregating, etc. And covering all these in the scope of the "ai_logging" module will be quite a challenge.
Proposed resolution
I believe that we can just use the standard PSR Logger interface to pass all the metadata to the log entry, and handle storing the metadata on the PSR Logger implementation side.
So, from the "ai_logging" module site (or maybe even do not create a separate module for this?), we just create a default Drupal log entry, which displays the most useful log data in the "message" text, that can be viewed and managed via any standard way in Drupal. And just pass all the additional metadata as context, which can be processed and stored in different ways.
A good candidate for storing custom data together with the PSR log entry is the
Extended Logger →
module that allows storing any metadata together with the log record. But this module is not required, so we can not introduce a hard dependency on it, but just recommend it as an option, if someone wants to get more detailed logs. And for most cases, the default Drupal Watchdog should be enough.
Remaining tasks
- Decide on the solution and finalize it.