Defect #6105
closedMigration 0.8 -> 1.0.0 : projects pages access = erreur
0%
Description
Hi,
after a migration from bitnami 0.8 => bitnami 1.0.0 I can't access to projects (menu or administration) :
IN LOG :
Processing AdminController#projects (for 84.99.210.210 at 2010-08-11 17:43:39) [GET] Parameters: {"action"=>"projects", "controller"=>"admin"} ActiveRecord::StatementInvalid (Mysql::Error: Unknown column 'lft' in 'order clause': SELECT * FROM `projects` WHERE (1=1 AND (status = 1)) ORDER BY lft): app/models/project.rb:210:in `find' app/controllers/admin_controller.rb:39:in `projects'
It seems projects table is not updated by upgrade steps (Wiki).
DB schema seems being wrong after upgrade.
From Web GUI all access to projects generate internal error.
Rhodan
Files
Updated by Felix Schäfer about 14 years ago
- Priority changed from High to Normal
Please provide the exact steps you followed to upgrade as well as any errors you may have had along the way.
Updated by Perry Rhodan about 14 years ago
During migration = none error
I followed step described in :
http://bitnami.org/article/how-to-backup-and-update-the-bitnami-redmine-stack
Dump MYSQL from initial DB
Backup Files
- Install new Bitnami module v1.0.0 in a new folder
- Restore DB
- Restore files
- $ rake db:migrate RAILS_ENV=production
- $ rake db:migrate:upgrade_plugin_migrations RAILS_ENV=production
- $ rake db:migrate_plugins RAILS_ENV=production
- $ rake tmp:cache:clear
- $ rake tmp:sessions:clear
At this step I need to modify manually users table data to add them to 'User' in place of 'null'. They wasn't visible in any list without.
But all request to projects :- main menu
- administration panel
... generate the error!
I check table for 'projects' after '*rake db:migrate RAILS_ENV=production*' and the index 'lft' and 'rgt' are missing :
DROP TABLE IF EXISTS `projects`; SET @saved_cs_client = @@character_set_client; SET character_set_client = utf8; CREATE TABLE `projects` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(30) NOT NULL DEFAULT '', `description` text, `homepage` varchar(60) DEFAULT '', `is_public` tinyint(1) NOT NULL DEFAULT '1', `parent_id` int(11) DEFAULT NULL, `projects_count` int(11) DEFAULT '0', `created_on` datetime DEFAULT NULL, `updated_on` datetime DEFAULT NULL, `identifier` varchar(20) DEFAULT NULL, `status` int(11) NOT NULL DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=24 DEFAULT CHARSET=latin1; SET character_set_client = @saved_cs_client;
the file 'db/migrate/20091220183509_add_lft_and_rgt_indexes_to_projects.rb' seems not to modify anythings.
Rhodan
Updated by Felix Schäfer about 14 years ago
Yes, because that migration only adds indexes, the columns for the project table should be created by migration 104. Can you provide a file list of db/migrate
in your 0.8 installation, and maybe a dump of the table schema_migrations
from the redmine db?
Updated by Perry Rhodan about 14 years ago
- File db_migrate__list.txt db_migrate__list.txt added
Here the list of files in initial 'db/migrate' folder
Rhodan
PS : do you wish the current schema (v1.0.0), because previous will be more complicated to get?
Updated by Perry Rhodan about 14 years ago
The schema migration table from my current install
Structure + Data
Rhodan
Updated by Felix Schäfer about 14 years ago
That one is the good one. This is very very strange, because the migration 104 has run correctly according to that schema_migrations table… I'll see if I can provide an sql file to create the columns, but I still find that "intriguing" to say the least.
Updated by Jesse Norell over 13 years ago
I have this same problem upgrading an old 0.8.4 system to 1.0.1-1 (debian package). db:migrate completed with no errors, but the schema isn't right.
What I ended up with:
mysql> describe projects; +----------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +----------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(30) | NO | | | | | description | text | YES | | NULL | | | homepage | varchar(255) | YES | | | | | is_public | tinyint(1) | NO | | 1 | | | parent_id | int(11) | YES | | NULL | | | projects_count | int(11) | YES | | 0 | | | created_on | datetime | YES | | NULL | | | updated_on | datetime | YES | | NULL | | | identifier | varchar(20) | YES | | NULL | | | status | int(11) | NO | | 1 | | +----------------+--------------+------+-----+---------+----------------+
What it should be:
mysql> describe projects; +-------------+--------------+------+-----+---------+----------------+ | Field | Type | Null | Key | Default | Extra | +-------------+--------------+------+-----+---------+----------------+ | id | int(11) | NO | PRI | NULL | auto_increment | | name | varchar(30) | NO | | | | | description | text | YES | | NULL | | | homepage | varchar(255) | YES | | | | | is_public | tinyint(1) | NO | | 1 | | | parent_id | int(11) | YES | | NULL | | | created_on | datetime | YES | | NULL | | | updated_on | datetime | YES | | NULL | | | identifier | varchar(20) | YES | | NULL | | | status | int(11) | NO | | 1 | | | lft | int(11) | YES | MUL | NULL | | | rgt | int(11) | YES | MUL | NULL | | +-------------+--------------+------+-----+---------+----------------+
Any pointers how to properly fix this?
Updated by Jesse Norell over 13 years ago
Also after the migration, all my users except admin are gone (maybe related, maybe not).
Updated by Etienne Massip over 13 years ago
You should check your schema_migrations
table contents to see which migration(s) has not being executed (compare with your 1.0.1 db/migrate
files (source:tags/1.0.1/db/migrate)).
The 104_add_projects_lft_and_rgt.rb
at least went wrong.
Updated by Jesse Norell over 13 years ago
schema_migrations has up to version=101 .. does that mean 102_add_custom_fields_editable.rb failed and all subsequent scripts weren't run?
I'm new to redmine (and ruby), but it sure seems like a breaking failure like this should print an error when running db:migrate. Do you know if that's been addressed in recent versions? (Or would that actually be a problem to report with the debian package?)
I'm off to find resources on troubleshooting db:migrate failures, pointers are welcome. Thanks!
Updated by Jesse Norell over 13 years ago
Jesse Norell wrote:
schema_migrations has up to version=101 .. does that mean 102_add_custom_fields_editable.rb failed and all subsequent scripts weren't run?
Note: no, it appears it was up to version=101 in the old redmine install, so I'm guessing wherever db:migrate failed, it rolled back all changes?
Updated by Etienne Massip over 13 years ago
Did you migrate the right database and set your RAILS_ENV
accordingly before running commands ?
What's the "Database schema version" returned by ruby script/about
(needs that you set your RAILS_ENV
too)?
Updated by Jesse Norell over 13 years ago
- File redmine-migrator.sh redmine-migrator.sh added
Etienne Massip wrote:
Did you migrate the right database and set your
RAILS_ENV
accordingly before running commands ?
Yes.
What's the "Database schema version" returned by
ruby script/about
(needs that you set yourRAILS_ENV
too)?
Database schema version 101. Full output (I assume the deprecation warning is ok?) is:
/usr/share/redmine/script/../config/../vendor/rails/railties/lib/rails/gem_dependency.rb:119:Warning: Gem::Dependency#version_requirements is deprecated and will be removed on or after August 2010. Use #requirement About your application's environment Ruby version 1.8.7 (i486-linux) RubyGems version 1.3.7 Rack version 1.1 Rails version 2.3.5 Active Record version 2.3.5 Active Resource version 2.3.5 Action Mailer version 2.3.5 Active Support version 2.3.5 Edge Rails revision unknown Application root /usr/share/redmine Environment production Database adapter mysql Database schema version 101 About your Redmine plugins Bots filter 1.02
That was obtained by running the attached script, which sets the env variables to locations used by the debian packages. Simply take out the "ruby /usr/share/redmine/script/about" and the "exit", and that's what I ran to do the migration, after creating the mysql database/user/permissions and importing the old sql dump (also ran without the redmine:load_default_data
, with same results). db:migrate doesn't complain at all .. any way to enable debugging with it ?
Updated by Jesse Norell over 13 years ago
Yeah, I added --trace (saw it in some posting I ran across) hoping to enable some debugging type messages ... unfortunately all it does is add this to the output:
** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate ** Invoke db:schema:dump (first_time) ** Invoke environment ** Execute db:schema:dump
Updated by Jesse Norell about 13 years ago
I made some progress on this, I think have even resolved this issue. (I now have the error mentioned in Defect #8477, but I think is unrelated, ie. the db:migrate appears to have went ok).
What I did is download various versions of redmine source .tgz's and tried to walk through upgrading at different versions. The db:migrate from there, or default environment or something, prints actual errors, which was very helpful in diagnosing the problem (the debian package db:migrate or environment hid the errors from me, or put them somewhere I didn't discover).
I first found I needed Rack version 1.0.1, and had 1.1, so install rails 2.3.5 gem and it brought in the right version of rack. The debian db:migrate never complained about rack, so may or may not have been an issue.
Next I would run the db:migrate until error, track and fix that error, re-import the sql dump and start again. Using a stock redmine-1.0.1.tar.gz, starting from the mysqldump of my old 0.8.4 database, here's what I did to get a working migration:
tar xzvf redmine-1.0.1.tar.gz cd redmine-1.0.1/ cp /etc/redmine/default/* config/ # mine wasn't called "default" but same gist rake config/initializers/session_store.rb # here's the fix, these scripts were trying to recreate tables # or add columns that already existed: rm db/migrate/20090704172358_add_member_roles_inherited_from.rb rm db/migrate/20090704172355_create_groups_users.rb rm db/migrate/20090503121501_create_member_roles.rb rm db/migrate/20091017213716_add_missing_indexes_to_member_roles.rb rake db:migrate RAILS_ENV="production" /etc/init.d/apache2 restart
And I guess I hope I ran the plugin migration stuff too, though at this time I don't have any plugins. :)
At that point it's running fine. I then proceeded to migrate to the debian backports 1.1.2-2 package, also seemingly without error (except that #8477 issue).
Updated by Marius BĂLTEANU almost 6 years ago
- Status changed from New to Closed
- Resolution set to Invalid
Updated by Marius BĂLTEANU almost 6 years ago
I'm closing this because it is longer valid (old Redmine versions, bitnami installation).