https://kotlinlang.org logo
Join Slack
Powered by
Completely unrelated to Kotest.. but I'm sketching...
# kotest-contributors
e
Completely unrelated to Kotest.. but I'm sketching out the concept of a small ORM/JDBC wrapper library. If anyone here is experienced in the domain and has any thoughts on it I'm all ears. 🧵
s
We use spring JDBC because I find that over complicated DSLs don't add a lot, when I want to write SQL by hand (especially as I'm usually doing semi complicated queries in postgres). If you added something that wasn't as tedious as Jooq but still low level could be popular. Like your syntax looks pretty good,
Copy code
mikrom.execute(
  Query("INSERT INTO books (author, title, number_of_pages) VALUES (?, ?, ?)"),
  listOf("JRR Tolkien", "The Hobbit", 310),
  listOf("George Orwell", "1984", 328),
)
this alone would be awesome,
Copy code
Using the compiler plugin, you can annotate your data classes with @RowMapped to automatically generate row mappers.
e
Thx! you sound pretty positive 😎 Once they get the literals in place it'll be even sexier!
Copy code
mikrom.execute(
  Query("INSERT INTO books (author, title, number_of_pages) VALUES (?, ?, ?)"),
  ["JRR Tolkien", "The Hobbit", 310],
  ["George Orwell", "1984", 328],
)
Re: jooq, I think it relies too much on codegen. I hate how codegen creates this weird dependency in your build where you need a DB, then you need to apply migrations, then you can generate code and now you can start compiling stuff... open eye crying laughing Are there other parts of it that get tedious?
s
The fact that writing a query in jooq required crazy api nesting, and then you can't even copy and paste the sql
Everyone knows sql, why bother to create another dsl on top of it
And don't give me type safety. Just write a test that uses a test container. Then you know the sql really works
a
I would suggest JDBI - it is rock solid and very thin layer, battle tested, popular
jOOQ is so 2015
IMO JDBI is a bit better than Spring JDBC. And we ditched SpringBoot and went totally framework-free, and it feels great
Re: "automatically generate row mappers." - JDBI does it without generation
here is another lightweight thing https://github.com/target/lite-for-jdbc
AFAIK it should be archived soon in favor of JDBI
s
We don't use spring boot either
a
JDBI automatically maps data classes to SQL rows and vice versa
and it has native support of transactions, which jOOQ does not do. and JDBI does not do anything else. does one thing, does it really well
s
Can you just write sql?
a
yes I just craft my SQL by hand.
using lots of advanced features of Postgres when needed
s
Ok cos i hate having to just a dsl to write sql
a
all I need is map data both ways, and transactions/isolation levels
s
Works for select* from table but anything complicated is a mess
a
exactly. and I can cut and paste my SQL, optimize it etc, and paste it back into my Kotlin code. WYSIWYG
s
Exactly what i do
. Sql files in resources
a
so we built 
lite-for-jdbc
then switched to 
JDBI
and very happy
we use partitions, isolation levels, do optimization fencing via 
MATERIALIZED
etc
JDBI never gets in my way
s
Right i do funcky stuff too
Postgis pgvect etc
a
cool
so 
lite-for-jdbc
is simple, fast, lean, etc. and it never got any traction. because JDBI does all that as well, and is popular and battle tested
with nice plugins and such
@sam in your sample repo you are saying "avoid the more advanced FP features that don't translate well to Kotlin." - can you explain which features?
s
Thinks like monad transformers and the like - it was more written back when kotlin was newer and Scala was still top of mind. I think these days Kotlin has settled into it's own idioms quite nicely.
👍🏼 1
e
I really wish my client would ditch Spring. Sadly I don't have much say as a contractor. They even migrated some of my Kotest/Gradle stuff back to JUnit and Maven. 😮‍💨
a
i feel your pain
but we've used JDBI with SpringBoot as well, very happy
Open in Slack
PreviousNext
Powered by