Created attachment 923860 [details]
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"
And also Oracle does not work:
2014-07-31 13:07:24,451 ERROR [SchemaUpdate] HHH000299: Could not complete schema update
This issue blocks development and execution of BPMS performance tests.
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:
mvn clean package exec:exec -Dscenario=HumanTask_all_Java -s postgresql-localhost.xml
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.
BPMS 6.1.0 DR1
Postgresql 9.3.4 / Oracle 11gR2
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.
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?
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.
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.
Created attachment 925151 [details]
performance framework patch
Is this one solved now? because it is still marked as urgent and it is not modified yet. Should I move it to modified?
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!
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.