A modern programming language that makes developers happier.

kotlinlang

Perhaps anyone at <#C0B8RC352|server> has interesting insights on this subject!

I think designing tables in Exposed allow to define a fine-grained database model using Kotlin syntax / type safety.
If you want advanced features with your entity API (like multi-column keys, check constraints, indices, cascades, etc.), won't you end up with something very similar to what exist in Exposed ?
I think that having an SQL based API allow more control over the storage model (with a counterpart that you might have to write more code/description).
An article that (I think) well describe relational model complexity is the Jooq "database first" blog post : <https://blog.jooq.org/truth-first-or-why-you-should-mostly-implement-database-first-designs/|https://blog.jooq.org/truth-first-or-why-you-should-mostly-implement-database-first-designs/>
Maybe it can help discover bumps on the road ahead.

<@U0169118S3H> good point and terrific article :+1::skin-tone-2:
I suppose in the end you will end up with a product that will (have to) support the features Exposed supports. I think the friction I am having with it is that for 80% of the tables this fine grained control is not needed, but for these entities you're still required to create the same amount of boilerplate code. I guess my goal with this would possibly be to reduce that