Redmine

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

1. Install new Bitnami module v1.0.0 in a new folder
2. Restore DB
3. Restore files
4. $ rake db:migrate RAILS_ENV=production
5. $ rake db:migrate:upgrade_plugin_migrations RAILS_ENV=production
6. $ rake db:migrate_plugins RAILS_ENV=production
7. $ rake tmp:cache:clear
8. $ 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.

• 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

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?

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.

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?

Also after the migration, all my users except admin are gone (maybe related, maybe not).

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.

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!

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?

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)?

rake db:migrate --trace ?

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

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).

I'm closing this because it is longer valid (old Redmine versions, bitnami installation).