I notice there is a mongodb branch. right now I am seeking a nosql (distributed db) . we are using workflow heavily. There are about 1.5T for the history data.
mongodb supports transaction now, is there any plan to merger the latest master branch to the mongodb branch. then I can start work on it.
Is it just for the historic data that you want NoSQL? Or does the whole DB need to be MongoDB for scale?
Just asking as there may be options to use a different approach (e.g. MongoDB as a datasource for history; async history pumping data to MongoDB). The more you can share about the volume of active instances and historical, the more help we may be able to give.
The MongoDB branch is pretty well tested by us but we’ve been waiting for others to kick it around too.
The mongodb branch just transtorm the rs table record into mongodb document with one table to one document,one column to one property. If you use mongodb like this,you loss rs db’s relation query power,can’t using document faced advantages . For example ,in mogodb we shoud save one process instance data all in one document,include process base info,history activity,historic vars,historic comments.
The mongodb repo was indeed a direct transformation of the relation model to mongo. The idea was to try out the (then newly released) transactions in Mongo and see how it behaved compared against a relational database. And of course to see if people had interest in contributing and building it further out.
If you look deeper into the code, you’ll see the basics are there but many methods are not yet implemented. As @ylyly states, it would need a revision of the way the data is stored to store it in a format more native to mongodb. So right now it is more in an experimental state than anything else.
by the way if I want to implement these @todo, where is the right start point? where can I get some documents?
[
](https://forum.flowable.org/u/joram)
Thanks,
Ken Cheng
Yes, what’s there works but it has not been fully implemented, optimized or heavily tested by us yet. We’d love feedback from people trying it out.
I’ve been exploring the MongoDB code for the past week. We have an extensive set of capabilities already using Mongo and we’d like to be able to use the same DB for all of our data/interactions.
What i did as part of my efforts is port the code from using the raw Java driver to using the Spring Data. i’ve also updated the mappers to take advantage of a few things and further implemented the data manager methods. for the most part it seems like everything works alright… the primary issue i keep running into is when i run the taskService.complete(task.getId()); method.
The exception/error i get is the following:
Exception in thread “main” org.flowable.common.engine.api.FlowableException: Cannot trigger execution with id 853ecbb5-4f26-11ed-8fd5-406c8fbc58b9 : no current flow element found. Check the execution id that is being passed (it should not be a process instance execution, but a child execution currently referencing a flow element).
When i run the same code using the h2 or postgresl it runs fine which leads me to think that something under the hood for Mongo persistence is not working correctly. I’ve reviewed the code, mappers, managers and even compared the underlying MyBatis SQL query and mappings… at this point i’m at a loss… Any suggestions or ideas of why the exception is thrown?
Thanks for the reply… i’ll see what i can do about a PR. I’ve done a bit of hacking on the code and it may not be in the same “structure” as the original. I have provided some additional context for hopefully a clearer cause.
Exception in thread "main" org.flowable.common.engine.api.FlowableException: Cannot trigger execution with id ffbe4df6-4fb5-11ed-993c-406c8fbc58b9 : no current flow element found. Check the execution id that is being passed (it should not be a process instance execution, but a child execution currently referencing a flow element).
at org.flowable.engine.impl.agenda.TriggerExecutionOperation.run(TriggerExecutionOperation.java:92)
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperation(CommandInvoker.java:88)
at org.flowable.engine.impl.interceptor.CommandInvoker.executeOperations(CommandInvoker.java:72)
at org.flowable.engine.impl.interceptor.CommandInvoker.execute(CommandInvoker.java:56)
at org.flowable.engine.impl.interceptor.BpmnOverrideContextInterceptor.execute(BpmnOverrideContextInterceptor.java:25)
at org.flowable.common.engine.impl.interceptor.TransactionContextInterceptor.execute(TransactionContextInterceptor.java:53)
at org.flowable.common.engine.impl.interceptor.CommandContextInterceptor.execute(CommandContextInterceptor.java:71)
at org.flowable.common.engine.impl.interceptor.LogInterceptor.execute(LogInterceptor.java:35)
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:56)
at org.flowable.common.engine.impl.cfg.CommandExecutorImpl.execute(CommandExecutorImpl.java:51)
at org.flowable.engine.impl.TaskServiceImpl.complete(TaskServiceImpl.java:213)
I’ve debugged and followed the code through the debugger and it seems as if the process being retrieved within the TriggerExecutionOperation getCurrentFlowElement (~line 53) is null. The execution object passed into the method is present, but perhaps not the version expected?
Looks like i may have found the issue. Appears to be a timing issue where the task was being potentially completed before the environment/engine could do all the underlying tasks. When i introduced a delay between the time of creation and the time of completion, it seemed to work correctly.
Glad you found the cause - I think it would have been difficult for us to guess without the code, to be honest. It would be great to have a PR, it’s so much easier to progress the engines when there’s contributions from the community.