Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1097088

Summary:

Drop DB should not be required when upgrading old version BPMS(6.0.0) to new version BPMS(6.0.1).

Product:

[Retired] JBoss BPMS Platform 6

Reporter:

yuli wang <yulwang>

Component:

jBPM Core

Assignee:

Kris Verlaenen <kverlaen>

Status:

CLOSED WORKSFORME

QA Contact:

Jiri Svitak <jsvitak>

Severity:

high

Docs Contact:

Priority:

high

Version:

6.0.1

CC:

mbaluch, xiabai, yulwang

Target Milestone:

---

Target Release:

---

Hardware:

Unspecified

OS:

Unspecified

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2014-11-25 21:43:28 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
old db	none
new db	none

Description yuli wang 2014-05-13 06:49:00 UTC

Description of problem:
Start some process instance in BPMS6.0.0.
Upgrade BPMS6.0.0 to 6.0.1
Keep data unchanged.
Open the process instance page, the old instance is never shown.

Version-Release number of selected component (if applicable):
6.0.1

How reproducible:
100%

Steps to Reproduce:
1.Start some process instance in BPMS6.0.0.
2.Upgrade BPMS6.0.0 to 6.0.1
3.Open the process instance page without db change.

Actual results:
The old process is never shown in the process instance list because the database is broken, attachment is database change.
if drop old database, the instance data can not be restored.


Expected results:
The old process is still shown and can be continue without any exception.

Additional info:

Comment 1 yuli wang 2014-05-13 06:49:40 UTC

Created attachment 895013 [details]
old db

Comment 2 yuli wang 2014-05-13 06:50:11 UTC

Created attachment 895014 [details]
new db

Comment 4 Walter Medvedeo 2014-05-13 07:46:26 UTC

This is a jbpm core issue.

Comment 5 Kris Verlaenen 2014-05-13 10:52:29 UTC

Could you elaborate how you are migrating from 6.0.0 to 6.0.1? Using a script, if so which?

Could you also check the setting of the hibernate.hbm2ddl.auto property in jboss-eap-6.1/standalone/deployments/business-central.war/WEB-INF/classes/META-INF/persistence.xml

I would recommend to upgrade the database using a script (which shouldn't require a drop of the database), not relying on hibernate auto-update of the tables, if you are upgrading a production database containing data.

Comment 6 cory 2014-05-14 01:20:37 UTC

Hi:

I using hibernate update model to upgrade BPMS.
 <property name="hibernate.hbm2ddl.auto" value="update" />

Excuse me ， i do not know how to create script?
You means, i create a script for all table and data?
But, if BPMS' table have any change , this script will invalid.

Comment 7 Kris Verlaenen 2014-05-15 22:47:49 UTC

Cory, 

I just started bpms-6.0.0.GA (database reconfigured to jdbc:h2:~/jbpm-migration in standalone.xml), created an instance of the Evaluation process (from https://github.com/guvnorngtestuser1/jbpm-console-ng-playground-kjar) and shut it down, then started bpms-6.0.1.GA (database reconfigured to jdbc:h2:~/jbpm-migration), and it did still show the process instance and task created, I could successfully continue the process instance there.

So when hibernate.hbm2ddl.auto is set to update, it should automatically be able to adjust to the changes without loss of data.

Could you provide more detail on how to reproduce (which process, in what state) and the server log that might give some indication as well?

Comment 8 cory 2014-05-20 01:43:31 UTC

(In reply to Kris Verlaenen from comment #7)
> Cory, 
> 
> I just started bpms-6.0.0.GA (database reconfigured to
> jdbc:h2:~/jbpm-migration in standalone.xml), created an instance of the
> Evaluation process (from
> https://github.com/guvnorngtestuser1/jbpm-console-ng-playground-kjar) and
> shut it down, then started bpms-6.0.1.GA (database reconfigured to
> jdbc:h2:~/jbpm-migration), and it did still show the process instance and
> task created, I could successfully continue the process instance there.
> 
> So when hibernate.hbm2ddl.auto is set to update, it should automatically be
> able to adjust to the changes without loss of data.
> 
> Could you provide more detail on how to reproduce (which process, in what
> state) and the server log that might give some indication as well?

Hi Kris,
My database is mysql 5.   
When i install BPMS6.0.0GA, db have some *_ID_SEQ tables.
Then i upgarde to BPMS6.0.1GA, db do not have these tbales.
You can see attachment 895013 [details](BPMS6.0.0) and attachment 895014 [details] (BPMS6.0.1)
Thanks

Comment 9 Kris Verlaenen 2014-11-03 14:49:14 UTC

Cory,

It is possible that tables are changed etc. (due to auto-upgrade, or you could manually run a script upfront to upgrade tables).  Once this is done however, the data in the old tables should still be there, and the process instances should be shown in the new version.  The description seems to indicate otherwise, and we are not able to reproduce this.

Kris

Comment 10 Kris Verlaenen 2014-11-25 21:43:28 UTC

Cannot reproduce this issue.  Please reopen with clear instructions on how to reproduce if the issue persists.

Comment 11 cory 2014-12-09 09:47:16 UTC

This issue can not reproduce BPMS 6.0.2. 
Thanks