We are working with Kotlin for about a year now in the backend, side-by-side with Java.

Recently we decided to re-evaluate our DB layer. When we started the project we used Hibernate, then moved to JOOQ. Hibernate feels old and full of boilerplate, while JOOQ was too Javaish for me. So we decided to give Exposed a chance.

Exposed is a pretty young framework (since 2016) with official support from JetBrains. It is pretty lightweight and declared as a prototype (whatever that means…). Developers are on the slack #exposed channel and very responsive (Thank you @tapac !). You’re not on Kotlin slack? get an invite here: http://slack.kotlinlang.org/

The readme is pretty straight forward. All you have to do is select whether you want to use DSL or DAO approach. On a high level, DSL means type safe syntax that is similar to SQL whereas DAO means doing CRUD operations on entities.

It is a matter of personal taste. Personally I prefer the DSL syntax as it is more flexible and more easy to reason what the SQL will look like. Note that in the DSL approach (at least the way we use it) there is some kind of duplication as you have both table object and a data class to represent entities. In hibernate for example it is expressed via annotations. I do see an advantage of having a clean domain class without ORM annotations since it feels will be easier to detach if required. Here is an example:

Our first use case was not that simple. We had to do an “upsert” (insert or update) to MySql table via batch. It is not yet supported out-of-the box but there is an issue #167 describing how to do that. After some tweaking, mainly due to the fact that MySql didn’t return any result we came up with something like this:

The above code will produce SQL similar to this:

INSERT INTO Cities (id, name) 
VALUES (15, 'Tel Aviv') 
ON DUPLICATE KEY UPDATE id=VALUES(id), name=VALUES(name)

What else?

Logging

Very easy to see the actual executed SQL. The readme shows how to write to standard output. Here is an example of using kotlin-logging:

DataSource and Connection

The “getting started” is easy, However I didn’t like the design decision to keep connections via TransactionManager on thread local by default. It doesn’t scale on large projects and multiple connections like we have. I wish it was more explicit.

There is a workaround in issue #93 and I tend to adopt it until a solution from the lib.

Documentation

Achilles' heel of Exposed (and developers are aware of it). Will do my best to help here starting with this blog post. Great open source are great because they are easy to use. Good documentation is a prerequisite.

Conclusion

I think Exposed DSL feats neat with Kotlin and has great potential. You definitely should try it.

Can it do better ?— yes!

Is it ready for production? well, we use it in production — so yes!

Want to read more? more on Exposed on my next post: https://medium.com/@OhadShai/bits-and-blobs-of-kotlin-exposed-jdbc-framework-f1ee56dc8840