dbResult

Runs block and hands back what it produced as a DataResult, turning the failures an application is expected to handle into DataResult.Failure and letting the ones that mean broken code go on being thrown.

The result style is opt-in throughout, and nothing under it returns a DataResult: queries throw, the way the driver throws, which is what keeps them usable from a try/catch and from a Spring @Transactional without either knowing this module exists. Reach for the result style where a failure is a value you want to carry - a fat client turning it into UI state is what it was written for.

There are three doors into it, one per width, and this is the widest:

• one query: RunnableQuery.asResult

• a transaction: transactionResult

• anything else - a db.execute { } block, a RawQuery.execute(), a whole call of your own: this

val senators: DataResult<List<Senator>> = dbResult {
    db.execute {
        createNativeQuery("SET LOCAL statement_timeout = 5000").execute()
        createNamedQuery("SELECT id, cognomen FROM senators WHERE province_id = @p")
            .fetchObjects<Senator>("p" to 7)
    }
}

Not around the queries inside a transaction. A dbResult there catches the failure, the block finishes normally, and OctaviusClient.transaction commits over the very failure that was caught - the same trap runCatching sets in the same place. transactionResult is the door for that width, and it rolls back on a returned failure rather than committing over one.

Parameters