I don't know if it is fair to call this a bug, but the errors I encountered may reveal places the install could be improved.
Whereas no problems whatsoever on a fresh install, on a Drupal 5.0 rc1 site, where earlier on I had been trying to update the project modules to 5.0 myself based on the 4.7 code, I had disabled the project and project_issues modules and removed them from the module directory, but tables still existed in the database.
the following tables already exist:
project_comments
project_issues
project_issue_projects
project_issue_state
project_projects
project_subscriptions
So, I had the following experience:
Install of modules
Untarred modules (into ./sites/all/modules)
Administer modules shows a nice Project group:
Project5.x-0.x-dev
Provides a project node type and browsing of projects.
Required by: Project issue tracking (disabled), Project releases (disabled)
Project issue tracking5.x-0.x-dev
Provides issue tracking for the project.module.
Depends on: Project (disabled)
Project releases5.x-0.x-dev
Provides a release node type to represent releases of projects.
Depends on: Project (disabled)
Install of modules
* Untarred modules (into ./sites/all/modules)
* Administer modules shows a nice Project group
Enabling project creates the following warnings:
user warning: Table 'project_projects' already exists query: project_install CREATE TABLE project_projects ( nid int(10) unsigned NOT NULL default '0', uri varchar(50) NOT NULL default '', homepage varchar(255) NOT NULL default '', changelog varchar(255) NOT NULL default '', cvs varchar(255) NOT NULL default '', demo varchar(255) NOT NULL default '', release_directory varchar(255) NOT NULL default '', version int(10) unsigned NOT NULL default '0', mail varchar(255) NOT NULL default '', documentation varchar(255) not null default '', screenshots varchar(255) not null default '', license varchar(255) not null default '', PRIMARY KEY (`nid`), KEY project_projects_uri (uri(8)) ) TYPE=MyISAM /*!40100 DEFAULT CHARACTER SET utf8 */; in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
I run update.php,but no update version offered for project module (1,2,3,4,no updates available).
An examination of the database tables shows that the project_projects table is correct anyway (but what if there had been changes?).
Invoked the devel module's “Reinstall module” on project (it calls hook_install or hook_update)
Upon hitting administer to enable the project issues, was advised of the following warning:
Database schemaOut of dateSome modules have database schema updates to install. You should run the database update script immediately.
Now there is an update available for project (1)!
I hit the update button; get warnings:
user warning: Table 'intranetssa.project_releases' doesn't exist query: update_sql ALTER TABLE project_releases DEFAULT CHARACTER SET utf8 in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
user warning: Table 'intranetssa.project_releases' doesn't exist query: update_convert_table_utf8 SHOW FULL COLUMNS FROM project_releases in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
user warning: Table 'intranetssa.project_releases' doesn't exist query: update_sql DELETE FROM project_releases WHERE nid NOT IN (SELECT nid FROM node) in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
user warning: Unknown column 'issues' in 'field list' query: update_sql INSERT INTO project_issue_projects SELECT DISTINCT nid, issues, components, help, mail_digest, mail_copy, mail_copy_filter, mail_copy_filter_state, mail_reminder FROM project_projects_tmp in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
I can still create a Project
I go ahead cheerfully to Administer > Modules and enable the module Project issue tracking.
No warnings.
Go to update.php, no updates available.
Do devel Reinstall modules, click on Reinstall project_issue project. Nice green confirmation of reinstallation.
Hit administer; told to run update; project_issue module update “1” now available.
Following message:
The following queries were executed
project_issue module
Update #1
Repaired 0 comments
Update #500
UPDATE {system} SET weight = 2 WHERE name = 'project_issue'
No error messages in log.
Enabled Project_releases module.
update.php finds no update available
same procedure (reinstall)
warning:
user warning: Duplicate column name 'snapshot_table' query: update_sql ALTER TABLE project_release_projects ADD snapshot_table tinyint unsigned default '1' NOT NULL in /var/www/intrasteinhardtsa/includes/database.mysql.inc on line 167.
The following queries were executed
project_release module
Update #1
CREATE TABLE IF NOT EXISTS {project_release_default_versions} ( nid int unsigned NOT NULL default '0', tid int unsigned NOT NULL default '0', major int unsigned NOT NULL default '0', PRIMARY KEY (nid, tid) ) TYPE=MyISAM /*!40100 DEFAULT CHARACTER SET utf8 */;
INSERT INTO {project_release_default_versions} (nid, tid, major) SELECT pp.nid, tn.tid, prn.version_major FROM {project_projects} pp INNER JOIN {project_release_nodes} prn ON pp.version = prn.nid INNER JOIN {term_node} tn ON tn.nid = prn.nid
INSERT INTO {project_release_default_versions} (nid, tid, major) SELECT prn.pid, tn.tid, MIN(prn.version_major) FROM {project_release_nodes} prn INNER JOIN {term_node} tn ON prn.nid = tn.nid LEFT JOIN {project_release_default_versions} prdv ON prdv.nid = prn.pid AND prdv.tid = tn.tid WHERE prn.version_major IS NOT NULL AND prdv.nid IS NULL AND prdv.tid IS NULL GROUP BY prn.pid, tn.tid
Update #2
Failed: ALTER TABLE {project_release_projects} ADD snapshot_table tinyint unsigned default '1' NOT NULL
My own usage report:
Set access privileges
Click on projects, none listed
Click on my projects, see my project
delete it
Create it again
click on projects, can see it now, click on project, can see project page
Hit view all issues
Hit submit
Created a number of issues, everything working now.
Comments
Comment #1
dwwthanks for the report. i'll go through this more carefully later, but a few quick comments:
a) yes, the 4.7.x-1.* to 5.x-* upgrade path is very weird, and not at all documented. :( especially if you had created any releases under the 4.7.x-1.* "release system".
b) the particular manner in which you did the upgrade seems to not follow the drupal conventions exactly, which is part of why you hit so many problems.
c) there are definitely some bugs in the process and things that should be fixed in code, not just in documentation, to make this work better.
thanks for trying it out and submiting such a detailed issue! i'll look into all of it more closely in the near future. we'll certainly fix it up before i branch for DRUPAL-5 and/or create the official 5.x-1.0 release.
muchas gracias,
-derek
Comment #2
hunmonk commentedthere is now basic documentation in place for the upgrade from 4.7.x-1.x to later versions. please try out the upgrade again according to those instructions and report back.
Comment #3
aclight commentedSince we haven't heard back, I'm assuming this is no longer a problem.
Comment #4
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.