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
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
journalstable indeed has nojournalized_typecolumn. Instead it has atypecolumn. - All rows in your
journalstable have a settypecolumn. - The largest value in your
schema_migrationstable is20100714111651(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.rbis 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
journalstable indeed has nojournalized_typecolumn. Instead it has atypecolumn.
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
journalstable have a settypecolumn.
chiliproject=# select count(id) from journals where type is null;
count
-------
0
(1 fila)
OK
- The largest value in your
schema_migrationstable is20100714111651(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)