ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
Error migrating from Redmine to ChiliProject 2.X.0 (Bug #690)
| Status: | Closed | Start date: | 2011-11-08 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Felix Schäfer |
% Done: | 0% |
| Category: | Journals / History | ||
| Target version: | - | ||
| Remote issue URL: | Affected version: | 2.4.0 |
Description
Hello there,
similar issue to #554, I am getting errors when trying to migrate from Redmine v 0.9.3.stable (mysql):
jhouse@sandbox01:/usr/share/chiliproject$ sudo rake db:migrate RAILS_ENV=production --trace ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate == BuildInitialJournalsForActsAsJournalized: migrating ======================= -- Building initial journals for Message -> 0.9718s -- Building initial journals for Attachment -> 49.0365s -- Building initial journals for Document -> 8.4196s -- Building initial journals for Changeset rake aborted! An error has occurred, all later migrations canceled: undefined method `repo_log_encoding' for nil:NilClass /usr/share/chiliproject/app/models/changeset.rb:92:in `committer' /usr/share/chiliproject/vendor/plugins/acts_as_journalized/lib/redmine/acts/journalized/creation.rb:90:in `send' /usr/share/chiliproject/vendor/plugins/acts_as_journalized/lib/redmine/acts/journalized/creation.rb:90:in `recreate_initial_journal!' /usr/share/chiliproject/vendor/plugins/acts_as_journalized/lib/redmine/acts/journalized/creation.rb:87:in `each' /usr/share/chiliproject/vendor/plugins/acts_as_journalized/lib/redmine/acts/journalized/creation.rb:87:in `recreate_initial_journal!' ./db/migrate//20100714111653_build_initial_journals_for_acts_as_journalized.rb:45:in `up_without_benchmarks' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/batches.rb:26:in `find_each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/batches.rb:26:in `each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/batches.rb:26:in `find_each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/batches.rb:66:in `find_in_batches' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/batches.rb:25:in `find_each' ./db/migrate//20100714111653_build_initial_journals_for_acts_as_journalized.rb:41:in `up_without_benchmarks' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:328:in `say_with_time' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:328:in `say_with_time' ./db/migrate//20100714111653_build_initial_journals_for_acts_as_journalized.rb:30:in `up_without_benchmarks' ./db/migrate//20100714111653_build_initial_journals_for_acts_as_journalized.rb:29:in `each' ./db/migrate//20100714111653_build_initial_journals_for_acts_as_journalized.rb:29:in `up_without_benchmarks' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:282:in `send' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:282:in `migrate' /usr/lib/ruby/1.8/benchmark.rb:293:in `measure' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:282:in `migrate' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:365:in `__send__' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:365:in `migrate' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:491 /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:567:in `call' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:567:in `ddl_transaction' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:490:in `migrate' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:477:in `each' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:477:in `migrate' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:401:in `up' /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:383:in `migrate' /usr/lib/ruby/gems/1.8/gems/rails-2.3.14/lib/tasks/databases.rake:112 /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:158:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:242:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.9.2.2/bin/rake:33 /usr/bin/rake:19:in `load' /usr/bin/rake:19 Tasks: TOP => db:migrate
I am running ruby 1.8.7:
$/usr/bin/ruby -v ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
History
Updated by Holger Just at 2011-11-08 10:58 pm
Welcome to ChiliProject :)
This issue is entirely unrelated to #554. But I think I have an idea on what is wrong. To verify that, could you please tell us which types of repositories you are using (Git, Mercurial, whatever)? Also please tell us which exact version of ChiliProject you are using.
Updated by Jesse House at 2011-11-08 11:23 pm
I'm not yet using chiliproject, as I am in the process of trying to migrate to it.
I pulled the latest code via git clone https://github.com/chiliproject/chiliproject.git
While it may be "entirely unrelated to #554" for you, that issue dealt w/ migrating from redmine to chiliproject and the errors that people were receiving when running the db migration. Felix requested that users experiencing a "similar issue" (I still encounter errors when trying to migrate my db) open a new ticket and write a note about it in #554.
Thank you for your help.
Updated by Holger Just at 2011-11-08 11:36 pm
I know from the code that it is unrelated. But that is not the point. I'd still like to ask you to provide the requested information about the repository types you use.
You should also note that you the stable branch is most suited for production installations as it only contains released code. We release about once per month. See ChiliProject Repository for more information.
I think the error is related to some Changeset values lingering in the database for repositories which were already deleted sometimes in the past. While this shouldn't actually happen, I have seen some cases of that in the wild. We probably need to update the migration to check this and can then just delete those orphaned entries from the database.
These issues surface because of unexpected data inconsistencies in your database which probably don't bother the normal operations. But as we touch many of these objects during a change of our object journaling these inconsistencies tend to cause issues there.
- Status changed from Open to Needs more information
Updated by Jesse House at 2011-11-08 11:44 pm
My initial redmine installation was done via apt-get on ubuntu. I had that installation integrated w/ various git repos.
The chiliproject code was pulled using git from the chiliproject github repo.
Is there any other info you need about the repository types I use?
Updated by Balazs Varga at 2011-11-18 09:59 pm
I've experience the same problem (same OS/Ruby environment, same trace) when i try to migrate from redmine 1.1.0 to last ChiliProject stable (pulled via git).
I used git repositories too in redmine.
Updated by Balazs Varga at 2011-11-18 10:10 pm
same error if i upgrade from redmine to ChiliProject 1.x (successfully) then i try to migrate 2.x ::sadpanda::
Updated by Péter Major at 2011-11-19 10:35 am
Hi,
this is probably related:
mysql> select distinct repository_id from changesets; +---------------+ | repository_id | +---------------+ | 5 | | 6 | | 7 | | 8 | | 10 | | 11 | | 12 | | 13 | | 14 | +---------------+ 9 rows in set (0.00 sec) mysql> select distinct id from repositories; +----+ | id | +----+ | 10 | | 11 | | 12 | | 13 | | 14 | +----+ 5 rows in set (0.00 sec)
So it looks like we have changesets from non-existent repositories. I believe it is safe to remove those unreferenced changesets, right? Could you confirm this?
- Status changed from Needs more information to Open
Updated by Felix Schäfer at 2011-11-21 10:11 am
Péter Major wrote:
So it looks like we have changesets from non-existent repositories. I believe it is safe to remove those unreferenced changesets, right? Could you confirm this?
The changesets for non-existent repos should be safe to remove, yes. In any case, they are "only" a cache, i.e. any info in there should still be in the repo too.
I'll see if I can update the migration for 2.5.0, I can't guarantee it though.
- Assignee set to Felix Schäfer
- Category set to Journals / History
- (deleted custom field) set to 2.4.0
Updated by Felix Schäfer at 2011-11-21 10:12 am
Balazs Varga wrote:
same error if i upgrade from redmine to ChiliProject 1.x (successfully) then i try to migrate 2.x ::sadpanda::
Could you please check if you have orphaned changeset entries in your database too? Thanks.
Updated by peter hicks at 2011-11-23 12:51 am
I can verify that the unreferenced changesets are the problem:
$ rake --trace db:migrate RAILS_ENV=production ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate == BuildInitialJournalsForActsAsJournalized: migrating ======================= -- Building initial journals for Message -> 0.7359s -- Building initial journals for Attachment -> 50.7142s -- Building initial journals for Document -> 6.2621s -- Building initial journals for Changeset rake aborted! An error has occurred, all later migrations canceled: undefined method `repo_log_encoding' for nil:NilClass mysql> select distinct repository_id from changesets; +---------------+ | repository_id | +---------------+ | 2 | | 7 | | 9 | | 15 | | 18 | +---------------+ 5 rows in set (0.03 sec) mysql> select distinct id from repositories; +----+ | id | +----+ | 2 | | 9 | | 15 | | 18 | +----+ 4 rows in set (0.00 sec) mysql> delete from changesets where repository_id = '7'; Query OK, 153 rows affected (0.08 sec) $ rake --trace db:migrate RAILS_ENV=production ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute db:migrate == BuildInitialJournalsForActsAsJournalized: migrating ======================= -- Building initial journals for Message -> 0.7165s -- Building initial journals for Attachment -> 47.7287s -- Building initial journals for Document -> 5.6042s -- Building initial journals for Changeset -> 730.6773s -- Building initial journals for Issue -> 461.2064s -- Building initial journals for TimeEntry -> 98.7687s -- Building initial journals for News -> 0.0389s == BuildInitialJournalsForActsAsJournalized: migrated (1344.7561s) =========== == AddChangesFromJournalDetailsForActsAsJournalized: migrating =============== -- Adding changes from JournalDetails
Still waiting on the rest of the output
Updated by Felix Schäfer at 2011-11-23 07:16 am
peter hicks wrote:
I can verify that the unreferenced changesets are the problem:
Thanks for the feedback.
Updated by Balazs Varga at 2011-11-25 07:55 pm
yes, i'm working with Péter Major, this output he pasted is mine too.
Felix Schäfer wrote:
Balazs Varga wrote:
same error if i upgrade from redmine to ChiliProject 1.x (successfully) then i try to migrate 2.x ::sadpanda::
Could you please check if you have orphaned changeset entries in your database too? Thanks.
Updated by Felix Schäfer at 2011-11-25 08:06 pm
Balazs Varga wrote:
yes, i'm working with Péter Major, this output he pasted is mine too.
Ah, thanks. Still not sure how those orphaned entries happened and if we should change the migration to work around them or just mention it in some documentation because it shouldn't happen. I'll try to have a look this WE.
Updated by Péter Major at 2011-11-25 08:13 pm
I have a very bad feeling I know why:
Back in the days I couldn't remove a repository (the project switched to git from SVN) from my project, so I just removed the repository from the DB allowing me to reconfigure SCM settings. This just suggests I wasn't very thorough when I removed stuff. :)
Don't know if others did this as well to get this error.
Updated by Felix Schäfer at 2011-11-28 06:55 pm
I'm still a little wary to touch that migration and to introduce code that works around manual DB changes. I'd rather write up some docs to explain how to solve this rather than to have it in the migration.
Jesse, can you confirm your issue is/was the same?
- Status changed from Open to Needs more information
Updated by Felix Schäfer at 2011-12-03 02:56 pm
I don't want to put model-specific branches in the migration for "inconsistent" databases unless really necessary, and as your the only cases I've heard for now I won't add any code to the migration.
I have updated the Upgrade docs to warn about possible inconsistency-related aborted migrations in the section for database migration though, I hope this will be enough. Closing for now.
- Status changed from Needs more information to Closed