Question about History Level

[brianrook]

We just upgraded from 5.2 to 5.6 and we're using DB2 as our RDBMS platform.  We are currently creating the database and seed data manually from the scripts because the 'automatic' DB upgrade tool doesn't work.  However, we ran into an issue last night that I am curious about.  My development and testing went fine with no hitches, but when I deployed to the build and test environment I got an error.  Activiti was looking for a property in ACT_GE_PROPERTY called historyLevel which wasn't present in the database and was not in any of the seed data from the scripts.  I 'fixed the glitch' by adding this property in manually and setting the value to 2, which I think corresponds to the default value of 'audit' of the history property that can be set on the process engine.

1)  If historyLevel is required in the ACT_GE_PROPERTY table, why isn't it set in the seed data?
2)  What is the relationship of the value in the table and the value in the configuration file?  Why are both needed and why do they have to agree?


Thanks,

[trademak]

Hi,

What Activiti configuration are you using? Could you post the activiti.cfg.xml contents or equivalent info?

Best regards,

[brianrook]

Here's the current Activiti configuration for that project:


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns:tx="http://www.springframework.org/schema/tx"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd
  http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-3.0.xsd">

  <bean id="processEngineConfiguration" class="org.activiti.spring.SpringProcessEngineConfiguration" >
    <property name="databaseType" value="db2" />
    <property name="dataSource" ref="documentDataSource" />
    <property name="transactionManager" ref="iipTransactionManager" />
    <property name="databaseSchemaUpdate" value="true" />
    <property name="jobExecutorActivate" value="false" />
    <property name="deploymentResources" value="classpath*:bpmn20/*.bpmn20.xml" /> <!– Deploy all process definitions –>
  </bean>
 
  <bean id="processEngine" class="org.activiti.spring.ProcessEngineFactoryBean">
    <property name="processEngineConfiguration" ref="processEngineConfiguration" />
  </bean>
 
  <bean id="repositoryService" factory-bean="processEngine" factory-method="getRepositoryService" />
  <bean id="runtimeService" factory-bean="processEngine" factory-method="getRuntimeService" />
  <bean id="taskService" factory-bean="processEngine" factory-method="getTaskService" />
  <bean id="historyService" factory-bean="processEngine" factory-method="getHistoryService" />
  <bean id="managementService" factory-bean="processEngine" factory-method="getManagementService" />


</beans>
I assume that this gives historyLevel the default value of "audit" which I think is equal to "2".


And here is the ACT_GE_PROPERTY insert statements:

insert into ACT_GE_PROPERTY
values ('schema.version', '5.6', 1);

insert into ACT_GE_PROPERTY
values ('schema.history', 'create(5.6)', 1);

insert into ACT_GE_PROPERTY
values ('next.dbid', '1', 1);

However, I get the historyLevel error with these values in that table until I add this one:


insert into ACT_GE_PROPERTY
values ('historyLevel', '2', 1);

which seems to enable it to work

[trademak]

Okay thanks. The history level in the database is the one used in the Activiti Engine.
The history level in the configuration is only used to fill the history level in the database.
If the history level is not set during the upgrade then that's probably a bug. Maybe it works if you set the history level explicitly in the configuration.
But if this works for you then that's good right?

Best regards,

[brianrook]

When we first encountered this problem, we added a history property in the process engine.  However, this would cause an error… I don't remember what it was off the top of my head, but we would see something like historyLevel 1 is not equal to 2 or something like that.  That's when we figured out that we needed a value in the database and added that insert ourselves.  Once we had that and made it agree with what was in the history property in the configuration file we were okay.

I was just concerned because it appears that a value is needed in the database, but it's not being inserted by the setup scripts.

[frederikherema1]

It's inserted by code when schema is created the first time, and inserted so you DON'T change the histry level on an existing engine (to prevent inconsistency of data and really really bad things from happening ). So changing the property in the database is a bad idea…

[jrussell]

We just ran into this ourselves, and the answer given is not acceptable.

Many envrionments (such as ours) do not allow the database schema to be maintaned by the application, rather by DBAs. Thus the databaseSchemaUpdate MUST be set to "false" and the database created/updated via external scripts by the DBAs.

Saying the only way for this to be set is by having update=true makes this product unusable for environments like ours.

For us, we were able to read the code and figure out what was missing, but this should be documented.