Hey folks, we’re looking into adopting exposed on the server-side for our new startup but have some concerns around the amount of boilerplate required • we define our migrations in a separate system so redefining the tables in exposed is troublesome, esp with drift. • we looked into the exposed gradle plugin but there’s some usability issues: ◦ multiple file codegen is disabled ◦ imports are incorrect which breaks compilation unless generated files are manually edited ◦ specifying schema in the connection properties doesn’t work - it pulls in all the tables from all the schemas Otherwise love the api and exposed itself, but just wondering how people deal with using exposed esp with separate migration systems (e.g flyway)

There is basically no reliable way to get rid of the boilerplate. I hope JetBrains will put more effort into Exposed some day.

Kinda unfortunate, its a pretty great library otherwise, any suggestions on other ORMs @nordiauwu, https://entgo.io/ is a nice, lightweight and typesafe orm in Golang, was looking for something similar

Well, Kotlin has always lacked a good ORM. I don't think there is something better than Exposed for now.

@Nayeem Zen we use liquibase migrations. Have db schema with more than 90 tables so it is really annoying to make some changes in Exposed DAO. We decided to implement liquibase xml parser that will parse all existing tables with names, columns, foreign keys etc... Then we use Kotlin Poet so we are able to generate Table entities for whole schema.

I used to use tbls to generate yaml dump of schema and then use a pebble template to generate Table and Entity classes from that. It was a bit hacky & DIY but worked. Recently moved to jOOQ for all data access. It has ben worked pretty well.

@lorefnon are you also using kotlin poet or just templates for generation. I’m also a fan of Jooq, but the object mapping support isn’t as good as exposed (but supports third party mappers 🤔 )

Curious what you find lacking in ObjectMapping ? The projection support has worked well for us, and compared to exposed I don’t find smth missing.

mostly around doing relational joins and having to map it manually or via using json serialization/multiset

Multiset operator is interesting. I was not aware of this. Thanks for sharing. The very few cases where I have attempted to load related entities in a single operation I used json - we mostly moved away from that pattern because cache handling gets complex.

Gotcha makes sense 👍

We use exposed with flyway. It’s not ideal. We’ve tried the

createMissingTablesAndColumns

method instead of using migrations for a while, but it doesn’t work if you need migration history with rollbacks etc and it also doesn’t work if you want to create materialized views etc. Right now we just write the code for the Exposed view manually in addition to the migration. It’s not trivial to verify the exposed schema with the actual schema defined via migration. But all in all, for us the benefit of using Exposed outweighs the gaps.