I'm working on that.. probably i have a first draft about it in two weeks from now.. For what i know, it will be included in 5.1. But i think that i could make it work soon. Ask to Mark and Kris about it. On Mon, Apr 6, 2009 at 7:30 PM, Marc Dzaebel <mdzaebel(a)web.de&gt; wrote: -- - Salatino Mauricio -

Marc, As Mauricio already pointed out, we have already have very concrete plans in adding separate persistence of process instance variables in the database. I expect this to be added to trunk in a few weeks time. This will allow pluggable persistence managers for all your variables based on the type of the variable (class or annotation). By default, we will include support for simply storing the value directly and support for JPA entities (as they are already stored separately), with the possibility to register other strategies. As you also noticed correctly, persistence is implemented orthogonally. This means it is indeed possible to completely replace the persistence with your own. We do however try to provide the most common feature requests out of the box, and you're lucky as separate variable persistence is one of them :) Another strategy that might be useful in a lot of use cases (not sure what yours is exactly so not sure it applies) is not querying on the runtime database but getting the information from the history logs. The drools-bam module for example shows how information about all running process instances (their state, which nodes were triggered, etc.) can be stored in a database. As this is implemented based on the generic listener interface, you can use this to create a persistent log of information using the model that suits your use cases. Notice that a history log is not only about completed process instances, but about currently executing ones as well. The advantage of this approach is that queries on the history log won't ever impact your running sessions and you can define what data to store yourself (and how), optimized to your use case. Kris ----- Original Message ----- From: "Marc Dzaebel" <mdzaebel(a)web.de&gt; To: <rules-users(a)lists.jboss.org&gt; Sent: Tuesday, April 07, 2009 12:30 AM Subject: [rules-users] JPA persistence for Drools Flow

Hi Kris, thanks for your thorough and quite helpful explanation! Kris Verlaenen wrote: So it could be in in Drools 5.0? I think the different strategies for process variables are exactly what we'll need. I'm glad to hear that standard use cases will be supported soon. Kris Verlaenen wrote: This is a quite innovative idea and it sounds logical to reuse historical data and gain the aibility to save and query your data appropriately. It might slow down db access as you'll have to select the lastest version of an instance in advance (might be achieved by a simple flag). May be the combination of out-of-the-box process/variable persistence and customized historical persistence promisses the most benefit. However, we should work out patterns/examples of how to persist searchable processes. -- View this message in context: http://www.nabble.com/JPA-persistence-for-Drools-Flow-tp22918819p22926924... Sent from the drools - user mailing list archive at Nabble.com.

Quoting Marc Dzaebel <mdzaebel(a)web.de&gt;: Probably not, Drools 5.0 is feature complete and should be released any time now. But we're planning to do much more smaller, incremental releases now, so Drools 5.1 shouldn't be too long. Agreed, it does not work for all use cases of course. Not sure what you mean by "select the latest version of an instance" though, as there is always only one version of a specific process instance (even in the history log). Note that the model of the history information is different from the runtime model, and contains all the nodes that were triggered (and possibly completed). So new data gets added to this process instance log every time something new happens, there's no different versions there. Kris http://www.nabble.com/JPA-persistence-for-Drools-Flow-tp22918819p22926924...

Kris Verlaenen wrote: If node states, process variables or the WM change (events), there should be new rows in some history tables (which I call versions), even if process/node refs won't change. However, I'm looking forward to your new persistence option in the trunc. -- View this message in context: http://www.nabble.com/JPA-persistence-for-Drools-Flow-tp22918819p22961161... Sent from the drools - user mailing list archive at Nabble.com.