AW: [jbpm-dev] Migration

[Joram Barrez]

Agreed,

It depends on how you look at it. In some use cases, it is conceptually
correct to see tasks, processes, etc as being part of the domain model. The
main advantage then of having direct access to a Hibernate sessions allows
to create queries that take in account own domain models and the bpm model.

eg. give me all the tasks involving documents with author X. With jBPM, this
is easy *and* accessible for average developers (who know Hibernate).

IMO, it is impossible to create an API that covers all these kinds of use
cases. It will be too complex and still be restrictive for some. In my
experience, people tend always tend to need that functionality that is not
supported out of the box (and the next customer finds another one ...)


But now for the compatibility isues, my opinon:

- When frameworks change, people understand that some code will need to be
rewritten. People understand that there is a price for the newer features.
eg. Hibernate code configured with XML -> annotations. I do believe that
there should be a  'compatibility mode', which means that jBPM3 process
definitions should be able to run on the jBPM4 engine. If this is feasible,
I think it will solve most of the people's problem with upgrading.

- DB conversions is, I think, more needed: some of the people I have worked
with have processes that an run up to 5 years. So for me conversion of DB
state is the most important.

Regards

Joram

On Thu, Oct 30, 2008 at 10:46 AM, Ronald van Kuijk <ronald at jbpm.org> wrote:

> 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
>
> _______________________________________________
> jbpm-dev mailing list
> jbpm-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbpm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20081030/9d04e139/attachment.html