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