Hi, why would one prefer Exposed over JOOQ? I hear some complains about lot of boilerplate code needed in case of Exposed. Can you sum up what are the key benefits of using Exposed?

I can only speak for myself, but my use case is that users can write “queries” against our system and I’m transforming those queries into SQL. I have a solution in place which I’m currently refactoring. I found Exposed very flexible and easily extendable when it came to some missing functions, and it works very well on how to represent different expressions in memory. I’m still in the middle of the work, and I never used jOOQ before (worked with Hibernate). In my current case, DB is already set up, persistence with Hibernate is set up, and I only needed a thing where I can efficiently work with SQL in memory and that’s where I found Exposed really handy. No annotations, no connection to the existing entities, I was simply able to rewrite my SQL schema with Exposed and then refer to those tables. But, honestly, if I’m about to start a brand new project, I’d just simply do Exposed because of the same things. Also, since it’s low level, you can build up your “kind-of-orm” (if you want). There are a few good articles out there about why not to use an ORM (which is a totally different topic) - I guess the main caveat is that you might need to write a few things for yourself. But again, it’s only my opinion, and I don’t have experience with JOOQ. But hope it still helps.

@Kuba Petržílka your question sent me on a deep dive. Does jOOQ's active record (hello Rails) support associations? I think it might be a much thinner DAO than Exposed. The SQL DSLs look very similar, jOOQ's is more fleshed out because it's an older library. I'm sure Exposed will get there.

@Joel I don't know much about JOOQ either, we have been using Hibernate so far. But the Exposed DSL seems better to me since JOOQ has only the Java's fluent notation, it is not a true Kotlin DSL. Also JOOQ forces you to generate the schema objects which I don't like..

I’m sure you can define them manually, but that is one of the core features

@Joel how do you handle migrations ?

fun Collection<Table>.migrateAll() {
    logger.warn("Migrating tables '{}'", map(Table::tableName))
    logger.debug("ddl {}", map(Table::ddl).joinToString())
    SchemaUtils.createMissingTablesAndColumns(*toTypedArray())
}

It's not a migration per-say, it just updates all the tables to match the current definition

@Joel i’m trying to wrap my head around the difference between

SchemaUtils.createMissingTablesAndColumns()

and db migrations using a tool like flyway, what effects do both have on a database, and what would work in a prod env?

Flyway is a dedicated migration tool. You can use that w/ Exposed, just make sure the mappings are the same on both sides. I don't ever find myself doing complex migrations, just adding columns and tables. So

SchemaUtils.createMissingTablesAndColumns()

has worked just fine.

Can be useful for those who used hibernate https://github.com/TouK/krush