Ktorm VS Exposed

I have been ktorm(https://www.ktorm.org) for a long time, and it suit with kotlin's stream operation very well

I mean, I'm looking at this, for example: https://github.com/kotlin-orm/ktorm/tree/master/ktorm-core/src/main/kotlin/org/ktorm/dsl, so I wonder, what would be gained from a matrix?

First google hit for "Kotlin ORM": https://github.com/kotlin-orm/ktorm

object TestDatabase { private val mySQLContainer: MySQLContainer = MySQLContainer("mysql:8.0.26").apply { withDatabaseName("test-db") withUsername("test-user") withPassword("test-password") start() // Start the container } init { val config = HikariConfig().apply { jdbcUrl = mySQLContainer.jdbcUrl username = mySQLContainer.username password = mySQLContainer.password driverClassName = "com.mysql.cj.jdbc.Driver" maximumPoolSize = 10 } val dataSource = HikariDataSource(config) // This doesn't connect to the database but provides a descriptor for future use // In the main app, we would do this on system start up // https://github.com/JetBrains/Exposed/wiki/Database-and-DataSource Database.connect(dataSource) // Create the schema transaction { SchemaUtils.create(Users) } } }

Exposed SQL is pretty good.

Exposed by JetBrains https://github.com/JetBrains/Exposed

Alternatively there are... hybrid solutions like Kotlin's https://github.com/JetBrains/Exposed or https://jdbi.org/ that don't quite... do all the heavy lifting for querying but allow you to sorta stitch queries together manually.

In our last episode (https://youtu.be/Uza\_dWsNMUs) we worked out how to save stock items in PostgreSQL (https://www.postgresql.org/) using the JetBrains Exposed library (https://github.com/JetBrains/Exposed). This time we refactor our existing file-based storage, extracting an interface that we can implement with files, in-memory, or with Exposed. For the database version, instead of replacing items in a table when they change, we choose to implement an append-only datastore. This keeps all the old versions of every row, using a query to select the latest versions when we want to see the current state. This has the advantage that we can rebuild the state of our system if things go wrong, and may also be faster than amending when we consider transactions. This is part 62 of an exploration of where a Test Driven Development implementation of the Gilded Rose stock control system might take us in Kotlin. You can see the whole series as a playlist https://www.youtube.com/playlist?list=PL1ssMPpyqociJNwykAOB9\_KEZVW7BW7m2 and the code on GitHub https://github.com/dmcg/gilded-rose-tdd If you like this, you’ll probably like my book Java to Kotlin, A Refactoring Guidebook (http://java-to-kotlin.dev). It's about far more than just the syntax differences between the languages - it shows how to upgrade your thinking to a more functional style. I have some free time between producing videos and working for team Gilded Rose. If you like these videos I'd like to work with you - please get in touch - [email protected]

I have used hikari and exposed to do this in the past with postgres, although other dialects are supported.

This falls apart as soon as you need to chain transactions across multiple services/DAOs. You end up making everything non-suspend or use suspendTransaction and have to pass the parent txn around which isn’t ideal (https://github.com/JetBrains/Exposed/issues/1477)

Whether or not we persue our Event Sourcing experiment from the lastepisode, we know that we want to store our stock data in a database ofsome sort. So today we investigate using the JetBrains Exposed library (https://github.com/JetBrains/Exposed) to write to and read from PostgreSQL (https://www.postgresql.org/).

I used exposed to access a database https://github.com/JetBrains/Exposed. You can use sqlite for the easiest setup.