Bug 1126422

Summary: Database schema compatibility broken: BPMS 6.0 -> 6.1
Product: [Retired] JBoss BPMS Platform 6 Reporter: Jiri Svitak <jsvitak>
Component: jBPM CoreAssignee: Mauricio Salatino <msalatin>
Status: CLOSED WORKSFORME QA Contact: Jiri Svitak <jsvitak>
Severity: urgent Docs Contact:
Priority: high    
Version: 6.1.0CC: kverlaen, mbaluch, mrietvel, msalatin, mswiders
Target Milestone: ---Keywords: TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-08-25 15:10:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
postgresql-console.log
none
performance framework patch none

Description Jiri Svitak 2014-08-04 12:09:48 UTC
Created attachment 923860 [details]
postgresql-console.log

Database schema compatibility broken BPMS 6.0 -> 6.1. I run the same performance tests which worked with BPMS 6.0 and now they are broken with 6.1.

I experience the problem with PostgreSQL (see the attachment):
2014-08-04 13:50:56,547 ERROR [SchemaUpdate] HHH000388: Unsuccessful: create table AuditTaskImpl (id bigint generated by default as identity, activationTime date, actualOwner varchar(255), createdBy varchar(255), createdOn date, deploymentId varchar(255), description varchar(255), dueDate date, name varchar(255), parentId bigint not null, priority integer not null, processId varchar(255), processInstanceId bigint not null, processSessionId integer not null, status varchar(255), taskId bigint, primary key (id))
2014-08-04 13:50:56,547 ERROR [SchemaUpdate] ERROR: syntax error at or near "generated"
  Position: 39

And also Oracle does not work:
2014-07-31 13:07:24,451 ERROR [SchemaUpdate] HHH000299: Could not complete schema update
java.lang.NullPointerException

This issue blocks development and execution of BPMS performance tests.

To reproduce:
1.) git clone http://git.app.eng.bos.redhat.com/git/jbossqe-process-flood.git
2.) have a postgresql database bpms accessible for user bpms and password bpms
3.) run command:
cd jbossqe-process-flood
mvn clean package exec:exec -Dscenario=HumanTask_all_Java -s postgresql-localhost.xml

Expected behavior:
No such exceptions are thrown in BPMS 6.1 for the same application code, compatibility works. Or at least the changes are communicated and documented.

My environment:
BPMS 6.1.0 DR1
Postgresql 9.3.4 / Oracle 11gR2

Comment 2 Mauricio Salatino 2014-08-05 09:43:39 UTC
Hi guys, did you run the migration script for the db schemas? -> https://github.com/droolsjbpm/jbpm/tree/master/jbpm-installer/db
This doesn't seems to be related with the tasks schema changes.

Comment 3 Jiri Svitak 2014-08-05 13:12:29 UTC
1.) This happens on *empty* PostgreSQL schema. jBPM was *always* able to generate its schema. Migration script can have sense only for existing schemas.

2.) QE was not informed about upcoming changes. Why is the schema compatibility broken anyway? Have you tried the steps I mention? What should be done to get it working?

Comment 5 Jiri Svitak 2014-08-06 06:06:35 UTC
Wrt. dialect - as I said the code is the same for both 6.0 and 6.1, that means including hibernate dialect. My code was working with all 6.0 builds and now it stopped working. If you tried the steps I told you, they were really simple, you would not need to ask to check the dialect.

You cannot separate my sentence from the context. In case of Oracle database, the schema was prepared by scripts. In case of PostgreSQL, the database was empty, so your suggestion for using migration script does not make sense in the case of PostgreSQL and the problem persists.

We need to find out why the existing code stopped working. The easiest way is to try the steps I provided, they are simple and straightforward. If we will find something, what needs to updated - persistence.xml, additional SQL commands, application code etc. we need to properly document it, so the customers moving from 6.0 to 6.1 will have clear guideline what to do. Or it is a product bug which needs to be fixed.

Comment 12 Maciej Swiderski 2014-08-08 10:16:33 UTC
problem is actually caused by H2Dialect being used as there are multiple persistence.xml files found. The one that causes issues comes from jbpm-test. jbpm-test should not be used in such scenarios as it's intended to provide quick start in standalone operations/tests.

See attached patch that solves issues for the 6.1 performance framework.

Comment 13 Maciej Swiderski 2014-08-08 10:17:22 UTC
Created attachment 925151 [details]
performance framework patch

Comment 14 Mauricio Salatino 2014-08-12 10:52:11 UTC
Is this one solved now? because it is still marked as urgent and it is not modified yet. Should I move it to modified? 
Regards

Comment 15 Marek Baluch 2014-08-12 13:20:01 UTC
Mauricio - Jiri will verify the fix from Maciej and we will close the issue (most probably as not a bug).

@Maciej - many thanks for helping out with this issue!

Comment 16 Jiri Svitak 2014-08-25 15:10:30 UTC
Thank you Maciej for the patch file! I can confirm that after apply it works correctly.

Closing the bug, because I have been able to get it to working state. However these changes required for 6.0 -> 6.1 migration need to be documented.