Problem with forum.module

By Roy on 24 Apr 2003 at 20:38 UTC

Hi,
I have installed a fresh cvs, installed the forum module, created a forum vocabulary and a term, and configured the forum module.
The first time I initiated the forum in the viewer I rceived the following error messages:

user error: Unknown column 'f.tid' in 'where clause'
query: SELECT COUNT(n.nid) AS count FROM node n, forum f WHERE f.tid = '1' AND n.nid = f.nid AND n.status = 1 AND n.type = 'forum' in /usr/local/apache/htdocs/drupal-cvs/includes/database.mysql.inc on line 75.

user error: Unknown column 'f.tid' in 'where clause'
query: SELECT COUNT(*) AS count FROM comments c, node n, forum f WHERE f.tid = '1' AND n.nid = f.nid AND n.nid = c.nid AND n.status = 1 AND c.status = 0 AND n.type = 'forum' in /usr/local/apache/htdocs/drupal-cvs/includes/database.mysql.inc on line 75.

user error: Unknown column 'f.tid' in 'where clause'
query: SELECT n.nid, n.created AS timestamp, u.name AS name, u.uid AS uid FROM forum f, node n LEFT JOIN users u ON n.uid = u.uid WHERE f.tid = '1' AND n.nid = f.nid AND n.type = 'forum' AND n.status = 1 ORDER BY timestamp DESC LIMIT 0, 1 in /usr/local/apache/htdocs/drupal-cvs/includes/database.mysql.inc on line 75.

user error: Unknown column 'f.tid' in 'where clause'
query: SELECT n.nid, c.timestamp, u.name AS name, u.uid AS uid FROM forum f, node n LEFT JOIN comments c ON n.nid = c.nid LEFT JOIN users u ON c.uid = u.uid WHERE f.tid = '1' AND n.nid = f.nid AND n.type = 'forum' AND n.status = 1 AND c.status = 0 ORDER BY c.timestamp DESC LIMIT 0, 1 in /usr/local/apache/htdocs/drupal-cvs/includes/database.mysql.inc on line 75.

user error: Unknown column 'tid' in 'field list'
query: SELECT tid, count(*) AS c FROM history h, node n, forum f WHERE f.nid = n.nid AND n.nid = h.nid AND n.type = 'forum' AND n.status = 1 AND h.uid = '1' GROUP BY tid in /usr/local/apache/htdocs/drupal-cvs/includes/database.mysql.inc on line 75.

Can anyone help with this?

Thanks

Comments

Problem with forum.module

WBHacker commented 24 April 2003 at 21:06

Are you using a database built prior to the lastest CVS install?

Not mentioned in the drupal-cvs CHANGELOG, but elsewhere on the Drupal site I recall seeing that the very field you mention was changed to 'tid' from 'id' as part of an effort to improve DB universality and such.

Suggest you diff the old and new .../drupal/database/database.mysql files, or grep 'em for the old and new name.

Not a big deal to dump, convert dumpfile, DROPDB, CREATEDB, then reload in PostgreSQL, (but something else is broken...).

Should be as easy in MouseSqueal as well, if not more so (ALTER TABLE?).

Bill Hacker

Thanks Bill..

Roy commented 25 April 2003 at 07:53

It will probably take some time till i'll get used to reinstall the db everytime I install a new version..

Database scheme not up-to-date

Dries commented 25 April 2003 at 08:27

Looks like your forum table is incorrect. Strange because the SQL database scheme in the nightly snapshots (and the CVS repository for that matter) is actually correct.

If you upgraded a Drupal 4.1.0 setup, make sure to run update.php; it will make the required database changes (it will add the tid field to the forum table, for example).

update.php

WBHacker commented 25 April 2003 at 18:38

Mmmmmm... update.php appears to be *highly* MySQL-specific.. I set out to convert it, but figured it was easier to do the do with the PostgreSQL pg_dump options and 'Joe'

OTOH, a plain English (Flams or Waloon, even) checklist of steps that need doing....

Bill Hacker

We should make sure update.ph

Dries commented 25 April 2003 at 19:33

We should make sure update.php is not MySQL specific - patches that improve update.php to this extend are hapilly accepted.

(I think I'll be installing PostgreSQL soon so I can help testing.)

MDB database abstraction layer

moshe weitzman commented 25 April 2003 at 22:12

We can strive to have a perfectly cross-compatible update.php, but it isn't totally possible while using the PEAR DB module. We run into trouble with DB maintainence tasks like creating or altering tables. Field properties have different syntax for each DB type - and there no ANSI fix for this. An example is 'auto-increment' in MySQL which maps to 'identity' in MSSQL.

The PEAR MDB module attempts to offer a database independent way to manage databases as well as query them. It is built on top of PEAR DB. I don't know if there are many disadvantages to using this as opposed to PEAR DB. One disadvantage is that MDB does not currently support MSSQL.

If we do go this route, it may get harder to maintain a database.mysql.inc which doesn't require PEAR. We may need to run all users, including mysql users, through MDB. I'm just guessing though. I have no actual experience with this.

In summary, more attention is cross-platform compatibility in update.php will help a lot, but grand changes are needed for the ideal solution ... Or maybe we can do away with update.php somehow.

if-statements

Dries commented 28 April 2003 at 07:41

As update.php is not performance critical, we could wrap the database specific parts in if-statements.

I was not upgrading from 4.1.0...

Roy commented 25 April 2003 at 23:21

just from a previously installed cvs but I created the tables from the old cvs database.mysql so I have downloaded yesterday the new database.mysql and recreated the tables with it. I did not check if there were any differences between these two files but anyway, the problem was solved.