Unknown columns 'level' and 'lid'
Melkor - January 21, 2009 - 11:01
| Project: | Spam |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
Hello All,
I have encountered the following errors on my upgraded 6.9 version. I have upgraded from 5.15.
These messages appear when I update a node, regardless of type.
* user warning: Unknown column 'level' in 'field list' query: INSERT INTO spam_log (level, content_type, content_id, uid, function, message, hostname, timestamp) VALUES(3, 'node', 0, 1, '_spam_log_trace', '89240dbc4b30c09cc89a68a1ef4779aa', '79.132.105.4', 1232534441) in /var/www/html/test_69/sites/all/modules/spam/spam.module on line 1839.
* user warning: Unknown column 'lid' in 'field list' query: SELECT lid FROM spam_log WHERE message = '89240dbc4b30c09cc89a68a1ef4779aa' in /var/www/html/test_69/sites/all/modules/spam/spam.module on line 1840.
* user warning: Unknown column 'level' in 'field list' query: INSERT INTO spam_log (level, trid, content_type, content_id, uid, function, message, hostname, timestamp) VALUES(1, 1, '', 0, 1, '_spam_log_trace', 'Failed to obtain a valid trid.', '79.132.105.4', 1232534441) in /var/www/html/test_69/sites/all/modules/spam/spam.module on line 1825.It seems that spam module do not update properly.
Kind regards,
Melkor
#1
Are you still having this problem? If so, there is an issue with the upgrade path. However, I upgraded and I have not run into this.
#2
Looking at the .installs, this was likely caused by an upgrade from 5.x-1.x straight to 6. There are no spam_update calls in 6.x's .install to handle 5.x-1.x schemas like there are in 5.x-3.x. And there was no level or lid field in 5.x-1.x.
At very least, we probably need a warning somewhere that "you MUST upgrade to 5.x-3.x before upgrading to 6." Though if we put that in the 6.x branch, most people won't read that warning until *after* they've converted to 6...
So maybe the solution is to look for something characteristic to the 5.x-1.x schema alone, look for it in _install, and if we find it, drop table spam*. Losing the Bayesian training shouldn't be all that much of a heartbreak.
#3
The newly added INSTALL.txt now discusses this. It explains:
----------
Upgrading:
----------
If upgrading from the 5.x-1.x or 5.x-2.x versions of the spam module, you MUST
FIRST upgrade to 5.x-3.0-beta1 BEFORE upgrading to the 6.x-1.x version of the
spam module. If you neglect this step, the spam module will not work correctly
and the only solution will be to completely uninstall it and reinstall it.
After upgrading from one version of the 6.x-1.x spam module to another, be sure
to always visit update.php to perform any necessary schema updates.
Is that sufficient?
#4
Are there any tables in 5.x-1.x or 2.x that wouldn't be in 6.1? If the possibility of that is there, it may be useful to point out that after uninstalling they'll still need to drop all tables starting with "spam" and then reinstall.
Other than that, looks great. Still a little worried that people won't actually be reading this until after they've already upgraded to 6 so it'll be too late for most, but there's only so much we can do about that.
#5
It's been so long since I last used those very ancient versions of the spam module that I truly don't remember.
Documentation has to be written under the assumption that it will be read. If we assume people won't read it, then why write it? And for those that choose to not read the documentation, well, maybe when things break they'll learn to read it in the future.
#6
Probably a good idea to include the "drop tables" caveat in there, then.
And I'm sure most people will read it. The problem is that most will read it *after* they upgrade to Drupal 6. Asking them to read the docs for every module they may be upgrading in 6.x before they've done the Drupal upgrade to begin with is probably a little much for most users.
I don't think modules supporting one major version of Drupal back is overboard -- which, in a way, is what we're doing. We're just not covering every instance of the Spam module for that major version, which is fine with me; we have to draw a line somewhere. But I think the problem the OP had would be understandable, even with the INSTALL.txt in 6.x stating what it now does.
An interesting tangent, but probably neither here nor there. :-) Again, there's only so much we can do.
#7
Documentation updated.
#8
Automatically closed -- issue fixed for 2 weeks with no activity.