User Tools

Site Tools


dr:logging

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
dr:logging [2006/04/09 15:51] fgmdr:logging [2020/11/23 17:23] (current) – external edit 127.0.0.1
Line 1: Line 1:
 ====== Logging module ====== ====== Logging module ======
 +
 +
 +===== The suggestion =====
  
 Currently, various modules within core and contrib use various tables to store historical (i.e. "write once, read sometimes, never update") data. The most obvious is the "watchdog" table, but others exist, including "accesslog", and "zeitgeist"'s eponym table. Currently, various modules within core and contrib use various tables to store historical (i.e. "write once, read sometimes, never update") data. The most obvious is the "watchdog" table, but others exist, including "accesslog", and "zeitgeist"'s eponym table.
Line 53: Line 56:
   </code>   </code>
   *  Eventually recorder functions fulfill their recording contract as they wish using the original function arguments. Having the recordee name as first parameter allows the recorder function to be potentially unique for several recordees.   *  Eventually recorder functions fulfill their recording contract as they wish using the original function arguments. Having the recordee name as first parameter allows the recorder function to be potentially unique for several recordees.
 +
 +===== Tuning =====
 +
 +An objection to this mechanism is the obvious cost of logging over situations without logging. This could be alleviated by switching the recording pairs on and off as a logging module setting. Instead of logging pairs and always invoking the recorder, the module could store a "on/off" setting for each pair, defined in admin/settings/logging. 
 +
 +That way, recordee could still send recording notifications, but they would be cut off at the logging module level before reaching the recorders if the site admin thinks he doesn't need them.
 +
 +===== Why bother ? =====
 +
 +This came from a need initially met with the current Zeitgeist module: there is, as of Drupal 4.7RC2, no formal way to register searches being performed. Chatting on irc://irc.freenode.net/drupal confirmed that. 
 +
 +The mere idea of adding code to search.module just to support zeitgeist, which is a contrib module (and not even a major one), seemed utterly illogical, although just adding _zeitgeist_store_search() within search.module/do_search() fulfilled zeitgeist's need for a clean way to grab search requests, so I didn't even suggest it.
 +
 +Considering this, I suggested a hook for search recorders, that could be used by any module wishing to record search queries, and not just zeitgeist. But discussion showed this was not felt to be sufficiently general to be upheld.
 +
 +I then thought on, and considered what sort of a more general contract-based mechanism could be used, that would both be extremely simple to use by recordees, so as to not affect them, and flexible enough to accomodate more general needs than just recording searches. This is the first draft of the result.
dr/logging.1144597867.txt.gz · Last modified: 2020/11/23 17:23 (external edit)