Agreed,<br><br>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. <br>
<br>eg. give me all the tasks involving documents with author X. With jBPM, this is easy *and* accessible for average developers (who know Hibernate).<br><br>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 ...)<br>
<br><br>But now for the compatibility isues, my opinon:<br><br>- 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.<br>
<br>- 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.<br><br>Regards<br><br>Joram<br><br><div class="gmail_quote">
On Thu, Oct 30, 2008 at 10:46 AM, Ronald van Kuijk <span dir="ltr"><<a href="mailto:ronald@jbpm.org">ronald@jbpm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bernd Rücker schreef:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
I don't get this:<br>
<br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
the underlying DB should IMO be considered an implementation detail of<div class="Ih2E3d"><br>
the iBPM engine. If that is not the case in jBPM3 it needs to get fixed<br>
in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say<br>
there is no DB migration needed.<br>
<br>
</div></blockquote>
<br><div class="Ih2E3d">
The whole state of my processes is in the database. Of course no direct<br>
access should be exposed, <br>
</div></blockquote>
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' .<div class="Ih2E3d">
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Maybe we can discuss If I need to migrate existing process instances (I<br>
would tend to say yes), <br>
</blockquote></div>
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.<br>
<font color="#888888">
<br>
Ronald</font><div><div></div><div class="Wj3C7c"><br>
_______________________________________________<br>
jbpm-dev mailing list<br>
<a href="mailto:jbpm-dev@lists.jboss.org" target="_blank">jbpm-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/jbpm-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/jbpm-dev</a><br>
</div></div></blockquote></div><br>