AnsweredAssumed Answered

please consider the manual upgrade usecase

Question asked by heymjo on Mar 6, 2012
Latest reply on Aug 20, 2012 by vlagorce
Hi,

I am currently investigating how we can best upgrade an existing live application from Activiti 5.8 to 5.9. Our deployments all have <property name="databaseSchemaUpdate" value="false"/> set because we need to control this process manually. The reason for this is that our application database do not have the rights to execute DDL, not uncommon from a security POV.

So i located the upgrade script org\activiti\db\upgrade\activiti.oracle.upgradestep.58.to.59.engine.sql and executed it on the target schema connected as an admin user. This worked fine, no errors. However restarting the application with Activiti 5.9 then gives me this error:


Caused by: org.activiti.engine.ActivitiWrongDbException: version mismatch: activiti library version is '5.9', db version is 5.8 Hint: Set <property name="databaseSchemaUpdate" to value="true" or value="create-drop" (use create-drop for testing only!) in bean processEngineConfiguration in activiti.cfg.xml for automatic schema creation
   at org.activiti.engine.impl.db.DbSqlSession.dbSchemaCheckVersion(DbSqlSession.java:492)
   at org.activiti.engine.impl.db.DbSqlSession.performSchemaOperationsProcessEngineBuild(DbSqlSession.java:884)
   at org.activiti.engine.impl.SchemaOperationsProcessEngineBuild.execute

This means that there is still something being done in code to upgrade the DB, outside of the upgrade script ? Can we not make the upgrade script self-containing so that upgrades can be more easily managed by infra ?

For now i did this and it seems to be ok.


UPDATE act_ge_property SET value_ = '5.9' WHERE name_='schema.version';

I looked at the difference between an automatic upgrade, there the schema.history field is set as well but i don't think that information is actually used anywhere else.

Can anyone confirm this is a valid approach ?

Outcomes