What's the current suggestion for an ORM library? ...

# announcements

[Édgar Sánchez Gordón]

What's the current suggestion for an ORM library? I lean towards something Kotlin-idiomatic, and I also kind of prefer light ORM's, OTOH I appreciate popularity and future-proofness (I know, I know, nothing is really future-proof, but still). Within these kind of loose constraints, all suggestions welcomed! (and thanks in advance, of course)

[HankG]

I just started experimenting with JetBrains Exposed for interfacing with SQLite. It's been pretty interesting. https://github.com/JetBrains/Exposed

[Robert Jaros]

you can check https://github.com/kotlin-orm/ktorm

[Claude Brisson]

If I dare to emit an opinionated statement, using SQL DSLs is a no-go to me ; I prefer to gather plain real SQL queries in a centralized model. I'm the author of a lightweight Java ORM (which I plan to rewrite in Kotlin, just for the fun of it), so not kotlin but perfectly usable from kotlin, which you can check here: https://github.com/arkanovicz/modality/tree/master/modality-core . One of its strong features is an automatic reverse engineering of the database model, meaning that it works out of the box.

[Édgar Sánchez Gordón]

@Claude Brisson In the .NET world I've used Dapper https://stackexchange.github.io/Dapper/, a micro-ORM, meaning you have to use SQL commands, while Dapper provides the conversion from/to objects. I like it, so I guess I agree with your "opinionated" statement 🙂

[frogger]

Using plain sql and spring jdbc here. Just removed the last lines of orm magic

[lorefnon]

We have been using projects in mybatis umbrella and have found kotlin support to be surprisingly good (Even though the docs are not so stellar)

We use liquibase for schema version control, and then generate support classes for CRUD operations (from the database) using mybatis-generator which can generate kotlin classes for you. When going beyond single-table CRUD operations, we can use mybatis-dynamic-sql directly for type safe database agnostic operations.

When writing queries which are very much dialect specific - we can pass raw SQL through mybatis mapper-annotations and mybatis implements these annotated interface behind the scenes taking care of mapping to and from kotlin beans.

Because all of these modes of access are internally backend by the same mybatis foundation, they use the same pool, caching strategy etc.

We have found it to be the best end-to-end solution for SQL mapping in kotlin.

[christophsturm]

i wrote a r2dbc based orm that i use for my own projects https://github.com/christophsturm/r2dbcfun

[Édgar Sánchez Gordón]

@lorefnon Thank you for the detailed account!

[gildor]

Completely agree with Claude. Using pure sql instead of clumsy DSL is the best approach
So SQLDelight is perfect match for this