Project

General

Profile

Actions

Defect #9821

closed

Rake db fails updating from 1.2.1 to 1.3.0

Added by pasquale [:dedalus] about 13 years ago. Updated almost 13 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
Database
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
Invalid
Affected version:

Description

Exec command => rake db:migrate RAILS_ENV=production fails with this message

Please install RDoc 2.4.2+ to generate documentation.
==  CreateChangesetParents: migrating =========================================
-- create_table(:changeset_parents, {:id=>false})
rake aborted!
An error has occurred, all later migrations canceled:

Mysql::Error: Table 'changeset_parents' already exists: CREATE TABLE `changeset_parents` (`changeset_id` int(11) NOT NULL, `parent_id` int(11) NOT NULL) ENGINE=InnoDB

Files

rakeDb--trace.log (5.75 KB) rakeDb--trace.log pasquale [:dedalus], 2011-12-16 09:25
schema_migrations.log (2.53 KB) schema_migrations.log pasquale [:dedalus], 2011-12-16 12:12
Actions #1

Updated by Etienne Massip about 13 years ago

--trace to get the failing migration?

Actions #2

Updated by pasquale [:dedalus] about 13 years ago

attached rakeDb woth trace log

Actions #3

Updated by Etienne Massip about 13 years ago

If the changeset_parents table did exist in the database before source:/tags/1.3.0/db/migrate/20110902000000_create_changeset_parents.rb was started, then it might have been created by a plugin or maybe did you update the schema_migrations table by hand?

Else, could you please drop the schema_migrations table contents here?

Actions #4

Updated by pasquale [:dedalus] about 13 years ago

Etienne Massip wrote:

If the changeset_parents table did exist in the database before source:/tags/1.3.0/db/migrate/20110902000000_create_changeset_parents.rb was started, then it might have been created by a plugin

I have backuped my db from 1.2.1 release and restored on 1.3.0: this table on my db don't exists.
Executing rake db command I have the error (no plugins installed).

If I execute the same command on new fresh db I haven't the error. But in the new db schema the new table changeset_parents exists, in the previous db schema no: maybe it's this the problem?

you update the schema_migrations table by hand?

No

Else, could you please drop the schema_migrations table contents here?

schema_migrations.log

Actions #5

Updated by Hannes Meier about 13 years ago

i ran into the same issue today from 1.2.2 to 1.3 using the 1.3 bitnami stack and just doing a cleandb > dbbackup.
Anyway 1.3 is running without problems with my old db.
Can i go with that or may i run into problems?

Actions #6

Updated by Jure Klancar about 13 years ago

I have same issue upgrading DB 1.2.1 (bitnami stack) in test environment.
Nevertheless, as Hannes, I can start new version withoout problems.
So I ask the same question: can I go with that?

Actions #7

Updated by Ah Kow Tan about 13 years ago

Same error when updating from 1.2.1 to 1.3

Actions #8

Updated by Etienne Massip almost 13 years ago

I don't get it, why would this changeset_parents table already be there at the time this migration is ran?

Do you use some plugin that could have created it?

Actions #9

Updated by Gonzalo Fernández-Victorio almost 13 years ago

I have been able to reproduce the same error with this sequence.

1.-Install Bitnami Redmine 1.3.0-1
2.-Restore backup of a Redmine previous version (I'm not sure, but I think it's 1.1.0)
3.-Invoking rake db:migrate

Obviously it was a mistake on my part: I should have drop and recreate the database entirely before step 2. I don't know if other people had the same problem. Hannes Meier seems to say he did clean the database, so maybe his error is different.

For those with the error and asking if it's OK, I understand they won't be able to upgrade to a future version until they fix their setup. In case the problem is similar to mine, the simplest fix could be to drop table, and relaunch rake.

Actions #10

Updated by Ah Kow Tan almost 13 years ago

Gonzalo Fernández-Victorio wrote:

I have been able to reproduce the same error with this sequence.

1.-Install Bitnami Redmine 1.3.0-1
2.-Restore backup of a Redmine previous version (I'm not sure, but I think it's 1.1.0)
3.-Invoking rake db:migrate

Obviously it was a mistake on my part: I should have drop and recreate the database entirely before step 2. I don't know if other people had the same problem. Hannes Meier seems to say he did clean the database, so maybe his error is different.

For those with the error and asking if it's OK, I understand they won't be able to upgrade to a future version until they fix their setup. In case the problem is similar to mine, the simplest fix could be to drop table, and relaunch rake.

Thanks, using Bitnami Redmine 1.3.0-1 too.
Here's what I do:
  1. Backup previous version of Bitnami Redmine (1.2.1), including mysql database and file attachments.
  2. Uninstall previous version of Bitnami Redmine
  3. Install Bitnami Redmine 1.3.0-1
  4. Restore mysql database
  5. Run this command: rake db:migrate RAILS_ENV=production
  6. Rake failed with this error: Table 'changeset_parents' already exists
  7. Then I did these:
    C:\Program Files\BitNami Redmine Stack\apps\redmine>mysql -u bitnami -p bitnami_redmine
    Enter password: ****
    Welcome to the MySQL monitor.  Commands end with ; or \g.
    Your MySQL connection id is 10
    Server version: 5.0.83-community MySQL Community Edition (GPL)
    
    Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
    
    mysql> drop table changeset_parents;
    Query OK, 0 rows affected (0.03 sec)
    
    mysql> commit;
    Query OK, 0 rows affected (0.00 sec)
    
    mysql> quit
    Bye
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>rake db:migrate RAILS_ENV=production
    ==  CreateChangesetParents: migrating =========================================
    -- create_table(:changeset_parents, {:id=>false})
       -> 0.1092s
    -- add_index(:changeset_parents, [:changeset_id], {:unique=>false, :name=>:changeset_parents_changeset_ids})
       -> 0.2184s
    -- add_index(:changeset_parents, [:parent_id], {:unique=>false, :name=>:changeset_parents_parent_ids})
       -> 0.2184s
    ==  CreateChangesetParents: migrated (0.5460s) ================================
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>rake db:migrate:upgrade_plugin_migrations RAILS_ENV=production
    Cannot find old migration table - assuming nothing needs to be done
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>rake db:migrate_plugins RAILS_ENV=production
    Migrating engines...
    Migrating acts_as_activity_provider...
    Migrating acts_as_attachable...
    Migrating acts_as_customizable...
    Migrating acts_as_event...
    Migrating acts_as_list...
    Migrating acts_as_searchable...
    Migrating acts_as_tree...
    Migrating acts_as_versioned...
    Migrating acts_as_watchable...
    Migrating awesome_nested_set...
    Migrating classic_pagination...
    Migrating gravatar...
    Migrating open_id_authentication...
    Migrating prepend_engine_views...
    Migrating rfpdf...
    Migrating ruby-net-ldap-0.0.4...
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>rake tmp:cache:clear
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>rake tmp:sessions:clear
    
    C:\Program Files\BitNami Redmine Stack\apps\redmine>
    

Can that be considered an successful upgrade?
So far the new Redmine seems to be working fine.

Actions #11

Updated by Etienne Massip almost 13 years ago

Ah Kow Tan wrote:

Can that be considered an successful upgrade?

Kind of, yes. But if this table was created by a plugin, then this plugin might not work as expected anymore (but btw it is not compatible with 1.3).

Actions #12

Updated by Ah Kow Tan almost 13 years ago

Etienne Massip wrote:

Ah Kow Tan wrote:

Can that be considered an successful upgrade?

Kind of, yes. But if this table was created by a plugin, then this plugin might not work as expected anymore (but btw it is not compatible with 1.3).

Thanks, I did not install any plugin, unless Bitnami does. I also couldn't find any changeset_parents in my Redmine 1.2.1 mysql dump.

Are those thing in C:\Program Files\BitNami Redmine Stack\apps\redmine\vendor\plugins considered plugins? My Administration -> Plugins says No data to display.

Anyway, so far my Redmine 1.3 is still so good.

Actions #13

Updated by pasquale [:dedalus] almost 13 years ago

Etienne Massip wrote:

But if this table was created by a plugin

This table isn't created by plugin (see my comment 4): before I restore my database from 1.2.1 to 1.3.0, browsing into him tho find this table produce 0 results: the table don't exists. After I restore db into 1.3.0 and then execute rake-db command, I have this error. It seems that we have some wrong in rake-db...

Actions #14

Updated by pasquale [:dedalus] almost 13 years ago

pasquale [:dedalus] wrote:

This table isn't created by plugin (see my comment 4)

To be more explicit:
  1. redmine db 1.2.1 haven't table changeset_parents;
  2. install new redmine 1.3.0 release with an empty new db;
  3. restoring db 1.2.1 in new redmine environment;
  4. execute rake-db command and this command fails because table changeset_parents already exists.

The problem is that in table migrations of db 1.2.1, isn't 20110902000000 value related to changeset_parents creation.
Restoring db 1.2.1 over new empty db 1.3.0, let migrations table unchanged (without 20110902000000 value) and let changeset_parents table in restored db.
In this situation, the rake-db command fails per incongruence between migrations table and restored db.

To solve this situation:

  1. Install new redmine enviroment 1.3.0;
  2. drop new empty db 1.3.0
  3. restore db 1.2.1 in new environment:
  4. execute rake-db command and all is fine;

Etienne, this behavior isn't a redmine bug?

Actions #15

Updated by Etienne Massip almost 13 years ago

No, it is not.

Now I understand why the table existed before:
  • you created a fresh bare 1.3 DB with its schema which is useless since it should be overwritten by the DB import
  • you made a full DB import over an existing base without replacing existing schema objects so the tables new in 1.3 remain

The upgrade process as described in RedmineUpgrade does not require any new DB creation?!

Actions #16

Updated by pasquale [:dedalus] almost 13 years ago

Etienne Massip wrote:

No, it is not.

Then we can close it as invalid because redmine works as expected

Actions #17

Updated by Etienne Massip almost 13 years ago

  • Status changed from New to Closed
  • Resolution set to Invalid
Actions

Also available in: Atom PDF