Differences

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

--- dr:zeitgeist [2005/11/30 07:19] – fgm
+++ dr:zeitgeist [2020/11/23 17:23] (current) – external edit 127.0.0.1
@@ Line 4: / Line 4: @@
 Ensuing discussion on [[irc://irc.freenode.net/drupal|#drupal]] and on the patch page suggested that:
   * the idea was interesting
@@ Line 13: / Line 14: @@
-===== Changes to watchdog =====
+===== Problems with the current patch =====
-  * add a new column (say, "data") to the watchdog table, to hold a php serialized content, or NULL
+If you look at the patch, what it basically does is this, along with the definition of a new block in search_block:
-  * modify bootstrap.inc/watchdog to pass a new parameter:
-<php>
+<code php>
+function _search_recent()
+  {
+  $sq = "
+  SELECT
+    distinct message query
+  FROM
+    {watchdog}
+  WHERE
+    (type = 'search') AND (message like '%(content).')
+  ORDER BY timestamp DESC
+  " ;
+  $q = db_query_range($sq, 0, 5);
+  $ar = array();
+  while ($o = db_fetch_object($q))
+    {
+    $term = substr(substr($o->query, 12),0,-16);
+    $ar[] = l($term, 'search/node/' . $term);
+    }
+  $output = theme_item_list($ar, NULL);
+  unset ($ar);
+  return $output ;
+  }
+</code>
+You'll notice the "substr" line is dependent of the current format of the watchdog entries, which means it will most likely break on any translated site. And I know drupal style does not like multiline queries.
+Also, processing is done in PHP whereas a better implementation would just ask the DBMS for the set of distinct entries in proper order to minimize the global workload.
+===== Changes to watchdog =====
+  * Implemented in v2 of the patch:
+    * add a new column (say, "data") to the watchdog table, to hold a php serialized content, or NULL
+    * modify bootstrap.inc/watchdog to pass a new parameter:
+<code php>
 function watchdog(
   $type,
@@ Line 24: / Line 58: @@
   $severity = WATCHDOG_NOTICE,
   $link = NULL,
-  $data = NULL) {</php>
+  $data = NULL) {
+</code>
 The new parameter could be used by modules aware of this new feature to store content of their choice in the watchdog along with the standard parameters, while retaining compatibility with existing call through the use of a default NULL.
@@ Line 35: / Line 70: @@
 In the current 4.6.x core, only watchdog module queries the watchdog table, and does so with queries like:
 <code sql>select w.* [...] from {watchdog} w</code>
 which means no outside modules should be impacted. These queries could be improved to avoid querying this additional column if it is not needed.
 ===== Changes to search =====
+  * Implemented in v2 of the patch:
+    * searches beyond "node" and "user" could be displayed too: this mechanism could be used by modules implementing hook_search, since the content, as a serialized object, could also store additional information for these modules.
+    * with this information available, recent searches could be displayed by unserializing these data instead of processing the HTML-formatted contents of the current columns, allowing full i18n compatibility.
   * having this new column available would allow search to store more usable information in the watchdog, typically by storing a serialized version of the query stats:
     * term searched
     * result count
     * something else ?
-  * with this information available, recent searches could be displayed by unserializing these data instead of processing the HTML-formatted contents of the current columns, allowing full i18n compatibility.
   * as suggested by Boris Mann, having this more resilient content would allow for this feature to serve better, possibly by creating a RSS feed on recent searches
-  * the current display, limited to a fixed count of recent searches, could be improved tby the addition of paging and optional display of the stats attached to the search
+  * the current display, limited to a fixed count of recent searches, could be improved by the addition of paging and optional display of the stats attached to the search
-  * searches beyond "node" and "user" could be displayed too: this mechanism could be used by modules implementing hook_search, since the content, as a serialized object, could also store additional information for these modules.
+===== TODO =====
+-11-29 8:33 chx says:
+If you want to win the developers' hearts then you change the trigger_error in _db_query to a watchdog call (avoid infinite loops! keep a static var about 'tried watchdog it') which stores the debug_backtrace and lift the debug_backtrace renderer from devel. The latter is a contrib module but this would be just great, i think two lines o' code and would make drupal a hell lot easier to debug.
+-1129 20:33 After further discussion, it looks like the idea is to log the debug_backtrace() information in the additional field.