Hi Kris,
thanks for your thorough and quite helpful explanation!
Kris Verlaenen wrote:
... 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.
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:
Another strategy ... is not querying on the runtime database but getting
the information from the history logs ... 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.
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.