Folks, I have a question if you don’t mind - what’...

# exposed

[hhariri]

Folks, I have a question if you don’t mind - what’s the main reason(s) you’ve chosen Exposed over other solutions?

[benkuly]

I like the lightweight API and DSL compared to e.g. SQLDelight. I also did have many runtime performance problems with SQLDelight. In contrast exposed with an H2 database is extremely fast.

[Emil Kantis]

I'm interested in switching from Exposed to SQLDelight, since I like writing SQL queries and it's hard to unit tests with Exposed entities (although perhaps those entities should only be used for data access and not business logic?)

[PoisonedYouth]

I choosed Exposed because JPA is too much magic. Exposed is giving me the minimum I need for the persistence layer. To get rid of the manual transactions in my business logic I wrap Exposed in a repository layer.

[phldavies]

Mainly due to the implied stability of it being JB backed, and the DSL being lightweight. That said, with the design around global state and a preference to move towards SQL-first we're thinking of switching to SQLDelight once we've validated the PSQL support for our use-cases.

[Carter]

I chose Exposed because it lets me switch between Sqlite for local development and Postgres once my server application is deployed to the cloud without really any code changes.

This makes it really easy to check out and build/run a ktor web application on the JVM without lots of local configuration changes.

[Dirk]

I was looking for a lightweight and Kotlin native access layer. Since SQLDelight does not support Oracle, this was not an option. I still had Jooq on my list from the past, but since this is fee-based, it didn't make the cut.

The fact that Exposed comes from the Jetbrains team was an added bonus.

[Endre Deak]

1. it's lightweight
2. simple
3. type-safe sql statement creation (no raw strings parsed)
4. extensible (easy to add your own functions and use them as they were part of the lib)
5. no magic - I'm using the DSL, not the DAO and even with some boilerplate (which imho is a manageable amount) I have full control over my tables and entities
I used it to create new databases but also to connect to existing schemas and in both cases I was amazed how simple and straightforward the work was

I even managed to write some simple wrappers around it's Database object so I could manage connections across multiple schemas and endpoints

[ESchouten]

JB backed, Kotlin first and no magic.
Sometimes I am unsure if stepping away from JPA was the right move.
While Exposed removed the magic part, it also introduced a lot of extra code to manage.
Especially the repositories with all the hand written queries, and to a lesser extent mapping the domain entities on the tables.
While DAO solves some of the query boilerplate, it is yet another class to manage.

[Andreas Scheja]

In general: type safe sql statements (including nullability), lightweight (we only use the DSL) and no magic 🙂. Sadly we have to work with a rather monolithic database that is shared over multiple applications, so we have one library which defines all the tables and keep the Repositories with the queries in the applications.

vs JPA: I like to have as much as possible immutable, which just isn't possible with JPA afaik. Plus, since you have to initialize everything you end up having to initialize everything with null, so you have to work around that framework-forced nullability in your code, which leads to lots of ugly/unnecessary code with `!!/?: error("shouldn't happen")`

vs SQLDelight: we have a lot of queries that we assemble during runtime, which doesn't work well with SQLDelight afaik.

[Wishnuprathikantam]

• Kotlin first
• Jetbrains backed
• Typesafe
• Simple API
• Can switch b/w different SQL dialects with minimum or no code changes. I use H2 with test data and for other envs use mysql / postgres and can switch b/w based on a conf file loaded.
• No annotations or magic
I use Ktor as the backend for my projects and I prefer ktor for the same reasons - simple API, no annotations magic.