Home Software Development Bye Bye Hibernate – Discovering alternate options to Hibernate in Kotlin | Weblog | bol.com

Bye Bye Hibernate – Discovering alternate options to Hibernate in Kotlin | Weblog | bol.com

Bye Bye Hibernate – Discovering alternate options to Hibernate in Kotlin | Weblog | bol.com


We’re additionally in a position to give JOOQ our area mannequin and let it routinely determine the mapping from the question into the area mannequin. JOOQ can do routinely match this based mostly on current JPA annotations within the area mannequin, the “best-matching constructor” or a customized mapper you present your self.

In our mission we solely used the metadata constants, whereas JOOQ has extra to supply. JOOQ additionally generates DAO’s as an illustration. We investigated implementing the generated DAO’s in our mission, however they included default strategies that we thought of not helpful. As an illustration, a way was generated to search for experiments by (alphabetic) vary of speculation. It appears this ‘choose by vary’ is generated for all fields and creates muddle.

Apart from, the generated DAO code doesn’t appear to take indexes under consideration. A lot of the queries would result in a full desk scan in the event that they had been used, which might closely impression efficiency. We see room for enchancment right here: JOOQ might use the indexes as an indicator of whether or not there may be any use case for the code and depart a extra concise DAO. This is likely one of the causes we focussed our efforts on utilizing the metadata constants.

Our conclusion about JOOQ:

  • JOOQ’s documentation is elaborate and makes the framework straightforward to make use of. Particularly when you’ve got an current database schema or plan on utilizing a database migration device like Flyway.
  • The metadata constants generally is a good type-safe question implementation, based mostly in your current database. Due to this we had been in a position to implement JOOQ with minimal boilerplate code concerning mappings to the information entry layer.
  • JOOQ is actively maintained with month-to-month releases and is essentially the most used ORM framework after Hibernate inside bol.com.
  • One extra notice is that JOOQ has a number of paid variations, that supply a wider vary of supported database dialects and extra options. Our database kind, Postgres, amongst different widespread ones are supported within the open-source model. Common databases like Oracle and SQL Server are solely supported within the paid variations.

Noteworthy point out: Krush

The additional added boilerplate in mapping between the area mannequin and the desk mannequin with Uncovered and Ktorm inspired us to search for an alternate, onto which we encountered Krush.

Krush relies on Uncovered and claims to be “a light-weight persistence layer for Kotlin based mostly on Uncovered SQL DSL.”. It removes the necessity for boilerplate mappings by including again JPA annotations to the area mannequin, which we’re used to from Hibernate.

Sadly, there is no such thing as a utilization of this framework inside bol.com and on GitHub the group additionally appears too small to contemplate for utilization in manufacturing. Due to this, we concluded that we’d not go to the extent of testing its behaviour. As a substitute, we are going to give Krush a detailed look every so often to see the way it develops.

Noteworthy point out: Spring JDBC

You won’t want all of the complexity that Hibernate/JPA has to supply. Switching to a special ORM framework altogether could be heavy as effectively. What if there would simply be an easier various within the ecosystem you’re already utilizing? One such various is on the market in all Spring initiatives: Spring JDBC!

Spring JDBC will give you a extra low-level method, based mostly on JDBC instantly. This generally is a good method for smaller initiatives that wish to write native queries.


Becoming a member of forces within the bol.com hackathon to research Hibernate alternate options in Kotlin was enjoyable and we realized loads in regards to the accessible alternate options on the market. Our largest studying is that there are 4 main methods of approaching the ORM world:

  • Database schema first, the method that JOOQ takes.
  • SQL DSL first, the method that Uncovered and KTORM take.
  • JPA annotations first, the method that Hibernate and Krush take.
  • Low stage, the method that Spring JDBC takes.

All these approaches include their very own set of benefits and drawbacks. For our use case JOOQ could possibly be a substitute for Hibernate in our Kotlin initiatives. JOOQ would permit us to modify ORM frameworks with minimal modifications and most type-safety, whereas protecting boilerplate at a minimal. The group and utilization additionally appear adequate to undertake the framework for utilization inside a manufacturing surroundings.

You will need to notice that doing a migration from one ORM framework to a different is a heavy course of that wants devoted time to make it work, together with efficiency checks. Hibernate generally is a legitimate ORM framework alternative in a mission. We hope that you’re now extra conscious of a few of the different frameworks you possibly can select from and the way they work.

1 Through the hackathon the mission group additionally reserved a small period of time to research alternate options for Hibernate Envers. Utilizing a special ORM framework then Hibernate can pose a problem once you nonetheless wish to have such out of the field auditing accessible, as Hibernate Envers can solely be utilized in mixture with Hibernate itself. The conclusion of the small investigation was that Javers promised to be an appropriate various, though this framework appears solely maintained by one individual. Alternatively, you would use a extra low-level method by utilizing database triggers that audit and log modifications.

2 Some time in the past Sander spent hours making an attempt to debug issues that had been associated to utilizing information lessons with Hibernate, which ultimately led him to the listed article and repository. An instance of such an issue is that the appliance tried to delete an object from the database, however by means of Hibernates magic underneath the hood the article was recreated after the deletion in the identical transaction, leading to no object being deleted. Utilizing one of the best practices from the listed article led to constant outcomes.



Please enter your comment!
Please enter your name here