AW: [jbpm-dev] Migration

Ronald van Kuijk ronald at jbpm.org
Thu Oct 30 05:46:40 EDT 2008


Bernd Rücker schreef:
> I don't get this:
>
>   
>> the underlying DB should IMO be considered an implementation detail of
>> the iBPM engine. If that is not the case in jBPM3 it needs to get fixed
>> in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say
>> there is no DB migration needed.
>>     
>
> The whole state of my processes is in the database. Of course no direct
> access should be exposed, 
What we should *not forget* is that there are users out there that use 
hql (or even sql) via the hibernate session which can be retrieved from 
a jBPM session. They do this since the api does not support everything 
but a kitchensink. e.g. retrieval of taskinstances or processintstances 
based on values of variables is not possible in jBPM. Implementing this 
and keeping it performant requires many indexes. The jBPM database is in 
fact (as the docs say) not optimized (index wise) for all kinds of 
usecases, so a dba should tune this. Besides that, jBPM supports 
injecting a hibernate session to be used for the tables, so direct 
access is always 'exposed' .

> Maybe we can discuss If I need to migrate existing process instances (I
> would tend to say yes), 
If we don't, but allow just convert processdefinitions, run old 
instances in jBPM 3 and new instances in jBPM 4, all kinds of BAM/BI 
implementation by customers will break (they have to adapt for querying 
2 databases) Retrieving tasklists will be more difficult, signalling 
instances etc.... So I tend to say yes as well.

Ronald



More information about the jbpm-dev mailing list