Hi!
It a question out of curiousity, not that I’m solving a particular problem.
What is the reasoning bihind MyBatis to be ORM of choice in Flowable? What kind of advatages does it provide if compared to Hibernate? Have you guys ever considered other ORMs in early days of Flowable engine?
Cheers,
Lauri
it allows moving the logic to XML configuration, so you can have for example a switch in the configuration or have an IF value=10 then select foobar
I am not an expert (I worked for several months with the tool)
So the basic idea is to move all the logic to the configuration layer (instead of creating code to do the same)
I am not a flowable developer but for a comparison between MyBatis (formerly iBatis) and Hibernate you can look at https://stackoverflow.com/questions/1984548/hibernate-vs-ibatis
@moraleda, thanks for the link, it seems that MyBatis is stronger choice when it comes to “extremely high throughput”. I wander if authors had this on the list of reasons why.
There is also article named Running Flowable on MongoDB and actual mongo db support for Flowable.
Interesting would it be possible to make a module to support hibernate for Flowable? What does it take to make one?
I think the actual MongoDB support is in a separate Repo - https://github.com/flowable/flowable-mongodb and seems to have been updated for 6.6.0. I think it gives you a pretty good idea as to what is needed to switch the database layer.
I think the bulk of the work would be to re-implement all the DataManager implementations (https://github.com/flowable/flowable-engine/tree/master/modules/flowable-engine/src/main/java/org/flowable/engine/impl/persistence/entity/data/impl) and configure them with the process engine. Also classes like the DbSqlSession (in https://github.com/flowable/flowable-engine/blob/master/modules/flowable-engine-common/src/main/java/org/flowable/common/engine/impl/db/) and transaction handling (https://github.com/flowable/flowable-engine/tree/master/modules/flowable-engine-common/src/main/java/org/flowable/common/engine/impl/cfg/standalone) would also need reimplementing.
I think there would be a lot of work to get this working and to be as well optimised as the MyBatis implementation.
Hey everyone,
I was not there when the decision was made to use MyBatis. However, what I can say is that MyBatis and Hibernate are entirely different beasts.
With MyBatis we have entire control over the SQL that gets sent to the DB, it is easily customizable based on a properties and we can provide different queries for different DBs. We are the ones that write the SQL that gets send over the wire and are not using an additional layer (like with Hibernate) in this case. We are not using the caching layer of MyBatis, we have our own caching layer for entities which we use to flush to the DB when the transaction commits. This is also highly optimised for our usecase, i.e. if we do an insert and then a delete in the same transaction we won’t send this instructions to the DB, think straight through process without wait state. The DbSqlSession is where that magic happens.
Why would you need to change the data layer to Hibernate? Hibernate uses JDBC which is the same as MyBatis and any other ORM that would be used for relational databases that support JDBC.
The links from @pstapleton are good to see how the data persistence layer can be changed. I also agree with him that it will be a lot of work to bring it to the same level as the current MyBatis implementation.
However, if you are asking for hibernate / JPA support for storing variables, Flowable already has that support out of the box. You can use JPA entities as variables and those will be stored and loaded correctly from Flowable through the JPA EntityManager. Have a look at JPAEntityVariableType.
Cheers,
Filip
We have a particular infrastructure - it puts a requirement to use hibernate plugins for very-important-enterprise-reasons. So we are obliged to to use hibernate everywhere. Original question comes from dilemma whats is easier: port such plugin to mybatis, or, may be, port flowable to hibernate (haha i know).
Anyway, thanks a lot for the answer!
I was there when the decision for Mybatis was made ;-). It’s for the reasons listed above: a minimal layer around JDBC that gives full control about how things exactly go to the database. A decision we haven’t regretted so far.
I wasn’t there when the decision was made but in a previous life I was involved with another workflow engine that used Hibernate. After taking over the project and fighting with the database queries for about 2 months (slow, inefficient queries, too much overhead for transactions, etc.) we ripped out Hibernate and switched to MyBatis and never regretted it either.