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 upgrading Chiliproject

Added by Manuel Villar Guijarro at 2012-05-02 07:19 am

I'm trying to upgrade chiliproject 1.0:

I start doing a backup of all the code, files and database. Then I simply follow the instructions:

git fetch origin
git checkout v3.1.0
/var/lib/gems/1.8/bin/bundle install

An error raises complaining about some libs that are no instaled, so I repeat after it's installation.

apt-get install libxslt-dev libxml2-dev
/var/lib/gems/1.8/bin/bundle install
[...]
Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem is installed.

I check the configuration and session storage and as everything seems OK, I go on:

diff config/configuration.yml.example config/configuration.yml
less config/initializers/session_store.rb
/var/lib/gems/1.8/bin/bundle exec rake db:migrate RAILS_ENV=production

An error raises again, I repeat the order with --trace to try to get more info.


/var/lib/gems/1.8/bin/bundle exec rake db:migrate RAILS_ENV=production --trace

** Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
** Execute db:migrate
UpdateJournalsForActsAsJournalized: migrating ===========================
-- Updating existing Journals...
rake aborted!
An error has occurred, this and all later migrations canceled:


undefined method `journalized_type' for #<WikiContentJournal:0x7fd5ed8e23b0>
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/attribute_methods.rb:260:in `method_missing'
/srv/www/chiliproject/app/models/journal.rb:114:in `method_missing'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:28:in `up_without_benchmarks'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/attribute_methods.rb:211:in `each_with_index'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:26:in `each'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:26:in `each_with_index'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:26:in `up_without_benchmarks'
/var/lib/gems/1.8/gems/activesupport-2.3.14/lib/active_support/ordered_hash.rb:115:in `each_pair'
/var/lib/gems/1.8/gems/activesupport-2.3.14/lib/active_support/ordered_hash.rb:115:in `each'
/var/lib/gems/1.8/gems/activesupport-2.3.14/lib/active_support/ordered_hash.rb:115:in `each_pair'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:25:in `up_without_benchmarks'
/var/lib/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'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:328:in `say_with_time'
./db/migrate//20100714111652_update_journals_for_acts_as_journalized.rb:24:in `up_without_benchmarks'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:282:in `send'
/var/lib/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'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:282:in `migrate'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:365:in `__send__'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:365:in `migrate'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:491:in `migrate'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:565:in `call'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:565:in `ddl_transaction'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract/database_statements.rb:136:in `transaction'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/transactions.rb:182:in `transaction'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:565:in `ddl_transaction'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:490:in `migrate'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:477:in `each'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:477:in `migrate'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:401:in `up'
/var/lib/gems/1.8/gems/activerecord-2.3.14/lib/active_record/migration.rb:383:in `migrate'
/var/lib/gems/1.8/gems/rails-2.3.14/lib/tasks/databases.rake:112
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `call'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:205:in `execute'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `each'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:200:in `execute'
/var/lib/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'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:151:in `invoke_with_call_chain'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/task.rb:144:in `invoke'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:116:in `invoke_task'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `each'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:94:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:88:in `top_level'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:66:in `run'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:133:in `standard_exception_handling'
/var/lib/gems/1.8/gems/rake-0.9.2.2/lib/rake/application.rb:63:in `run'
/var/lib/gems/1.8/gems/rake-0.9.2.2/bin/rake:33
/var/lib/gems/1.8/bin/rake:19:in `load'
/var/lib/gems/1.8/bin/rake:19
Tasks: TOP => db:migrate

Any ideas?


Replies (4)

RE: Error upgrading Chiliproject - Added by Manuel Villar Guijarro at 2012-05-08 07:24 am

No ideas? Should I file a bug?

I don't use the wikis in chiliproject, so is it posible to bypass this error? (undefined method `journalized_type' for #<WikiContentJournal:0x7fd5ed8e23b0> )

RE: Error upgrading Chiliproject - Added by Holger Just at 2012-05-08 07:44 am

It looks like the saved information about your run migrations are inconsistent. Here, it seems like the migration 20100714111652_update_journals_for_acts_as_journalized.rb is tried to be run again.
To verify this, could you please have a look into your database and confirm the following pieces of evidence (make sure to not actually change anythong):

  • Your journals table indeed has no journalized_type column. Instead it has a type column.
  • All rows in your journals table have a set type column.
  • The largest value in your schema_migrations table is 20100714111651 (the one before the borked migration). You can check that with a SQL query like this:
    SELECT MAX(CAST(version as INTEGER)) FROM schema_migrations;

If all of theses evidences are true you can mark the migration as being already run. However, you should be very careful as messing with the migrations has a large potential to really mess up your database. So before manually changing anything (including upgrades) make sure to have a working backup.

RE: Error upgrading Chiliproject - Added by Manuel Villar Guijarro at 2012-05-08 09:07 am

Holger Just wrote:

It looks like the saved information about your run migrations are inconsistent. Here, it seems like the migration 20100714111652_update_journals_for_acts_as_journalized.rb is tried to be run again.
To verify this, could you please have a look into your database and confirm the following pieces of evidence (make sure to not actually change anythong):

  • Your journals table indeed has no journalized_type column. Instead it has a type column.

chiliproject=# \d journals
Tabla «public.journals»

    Columna    |            Tipo             |                          Modificadores                          
---------------+-----------------------------+-----------------------------------------------------------------
 id            | integer                     | not null valor por omisión nextval('journals_id_seq'::regclass) 
 journaled_id  | integer                     | not null valor por omisión 0 
 user_id       | integer                     | not null valor por omisión 0 
 notes         | text                        |  
 created_at    | timestamp without time zone | not null 
 version       | integer                     | not null valor por omisión 0 
 activity_type | character varying(255)      |  
 changes       | text                        |  
 type          | character varying(255)      | 

Índices:
"journals_pkey" PRIMARY KEY, btree (id)
"index_journals_on_activity_type" btree (activity_type)
"index_journals_on_created_at" btree (created_at)
"index_journals_on_created_on" btree (created_at)
"index_journals_on_journaled_id" btree (journaled_id)
"index_journals_on_journalized_id" btree (journaled_id)
"index_journals_on_type" btree (type)
"index_journals_on_user_id" btree (user_id)

OK

  • All rows in your journals table have a set type column.

chiliproject=# select count(id) from journals where type is null;
count
-------
0
(1 fila)

OK

  • The largest value in your schema_migrations table is 20100714111651 (the one before the borked migration). You can check that with a SQL query like this: [...]

chiliproject=# SELECT MAX(CAST(version as BIGINT)) FROM schema_migrations;
max
----------------
20110519194936
(1 fila)
NOT OK

If all of theses evidences are true you can mark the migration as being already run. However, you should be very careful as messing with the migrations has a large potential to really mess up your database. So before manually changing anything (including upgrades) make sure to have a working backup.

RE: Error upgrading Chiliproject - Added by Manuel Villar Guijarro at 2012-05-08 11:39 am

After revising the missing upgrades, I marked 20100714111652 and 20110729125454 as done and could finish the migration process. No other problems arose so I could finish the upgrade.

Thank you Holger!!!

(1-4/4)