Oh, I should have stated some of the discrepancies found between the table created following the sourceforge migration notes and the table created by Hibernate.
1. The duedate_ is created as a timestamp column in the "sourceforge" database while it is a datetime column in the "hibernate" table.
2. The sourceforge database does not include the appropriate foreign keys from the jbpm_job table.
3. All of the records migrated from the jbpm_timer table to the jbpm_job table result in a retries_ value of 0 (which renders the unacquirable).
I just unpacked the jbpm-jpdl-3.2.3.zip file and was surprised to discover that the very same release notes distributed on sourceforge are included (in release.notes.html). So, what am I missing? Why are the tables created by hibernate (in a clean database) different than those created using the release notes?
1: maybe because the db is different?
2: Everything on SF should be regarded as out-of-date I think. There indeed was an issue which was fixed in newer 3.2.x releases (afaik)
3: I've heard something like this before. Not realy sure, but it might require manual changes to those values.
The release notes included in the jbpm-jpdl-3.2.3.zip file contain the very same SQL migration steps as those posted on source forge. So, my questions remain. And of upmost importance...
- why is the retries_ column explicitly set to zero for all of the the records migrated from the jbpm_timer table to the jbpm_job table (rendering the jobs unacquirable)?
The db migration script is from the moment that 3.2 GA became available. Might be that between 3.2 GA and 3.2.3 something changed in the jBPM code that makes it unusable as it is.
From the code (I assume you analysed that to) I see inital jobs get retries=1 and the select statement does indeed a >0, so try setting it to 1 for jobs that are have not run yet
BUT TRY IT IN A TEST SYSTEM FIRST!!!! And use it at your own risk, I'm just a ;-)
Yes, I did look at the code and the select statement and observed the same thing (that retries_ must be > 0 for a job to be considered acquirable). After changing the statement that migrates data from jbpm_timer to jbpm_job such that retries_ is set to 1 (instead of 0), my jobs ran (as required).
That said, can someone from the jbpm group post an updated migration script that is in line with the code as of 3.2.3?
well, since you are part of the jBPM 'community', and you confirmed it works when changing 0 to 1, you might file a Jira issue. That is the way the 'jBPM group' is notified and take action. When that is done, I'll be more than happy to update the release notes.
One question though. Jobs that already ran do not run again, right? Please mention that in the jira issue as well