[drupal-devel] [bug] Do not drop the complete accesslog on 4.6 update

Goba drupal-devel at drupal.org
Sat Jan 22 15:31:41 UTC 2005


 Project:      Drupal
 Version:      cvs
 Component:    other
 Category:     bug reports
 Priority:     normal
 Assigned to:  Goba
 Reported by:  Goba
 Updated by:   Goba
 Status:       patch
 Attachment:   http://drupal.org/files/issues/Drupal-fix-stat-path-and-updates.patch (2.09 KB)

Well, first things first. Fix at least the association between the
accesslog data and the nodes. The attached patch fixes the path alias
issue in stat module and also adds the proper path values when doing
the accesslog table update. I also came up with some title update code,
but that only works with MySQL 4.0.4 and up, so I commented it out. It
still can be used by those advanced users, who would not like to loose
their data and have an uptodate MySQL setup.

Goba



Previous comments:
------------------------------------------------------------------------

January 21, 2005 - 17:20 : Goba

Attachment: http://drupal.org/files/issues/Drupal-do-not-drop-accesslog.patch (1.02 KB)

The introduction of the access log id was made into an update, which
drops the acceslog, and then recreates the table just to add a primary
key. This is perfectly possible without loosing any data, and is
documented in the MySQL docs. Patch attached.

BTW the 'path' introduction before instead of using 'nid' was also
buggy in the update, since it does not fill the 'path' values of the
items, so all previous log items are invisible. That also needs to be
fixed, but before it is fixed, I need input on the intended value of
the 'path' field.

In HEAD, statistics.module gets the path alias if available and stores
that in the 'path' (line 77 currently). But then node/%d is matched
with the path (line 174 currently), when a node access tracker is
printed, so those nodes with path aliases are not working with it. It
seems to me that the storage should be modified to not store the alias,
but let it be computed when needed (eg. when printing links). But I am
unsure, why was the alias stored. If this is fixed, we can get back to
fixing the update to actually provide the 'path' value, before removing
the 'nid', so that old accesslog items are still fully powering the site
admin after the update.

------------------------------------------------------------------------

January 22, 2005 - 11:11 : Dries

Committed the patch against updates.inc to HEAD.  Good catch.

As for the path/nid-problem: you are right when you say that we should
store the internal URLs and not the path aliases.  That would be a
bug.

Accessing the various statistics pages under "administer > logs" is
still quite slow so if you see room for improvement, let me know or
implement it in your next patch. ;)  On drupal.org, the accesslog-table
grows big (see bellow) and gets joined against one or more other tables,
or queried using pattern matching...  I think the table needs and index
on accesslog.url, and possibly on other columns as well.


mysql> SELECT COUNT(aid) FROM accesslog;
+------------+
| COUNT(aid) |
+------------+
|     431674 |
+------------+

Lastly, on the mailing it was suggested that we track user agents. 
Maybe it is worth adding an accesslog.agent-column.  Or maybe that
should be watchdog.agent?  Or both?

-- 
View: http://drupal.org/node/15962
Edit: http://drupal.org/project/comments/add/15962





More information about the drupal-devel mailing list