mvysny / vok-orm

Mapping rows from a SQL database to POJOs in its simplest form
MIT License
21 stars 4 forks source link

Provide KotlinMapper as rowMapper for Dao/DaoOfAny #14

Open stapel opened 4 years ago

stapel commented 4 years ago

JDBI supports proper mapping to Kotlin-classes via the jdbi3-kotlin plugin. The DaoOfAny class from jdbiorm only provides a Java-FieldMapper, this works to some extent with Kotlin.

The FieldMapper requires you to use default-values for all data-class properties, because the data class will be constructed using the default constructor () and filled afterwards. The KotlinMapper directly constructs the data class with the values provided (properties not present in the constructer will be filled afterwards).

Better and further description can be found here: https://github.com/jdbi/jdbi/tree/master/kotlin

Maybe vok-orm could provide/register the plugin and convenience-classes like:

open class KtDao<T : AbstractEntity<ID>, ID>(entityClass: Class<T>) : Dao<T, ID>(entityClass) {
    override fun getRowMapper(): RowMapper<T> = KotlinMapper(entityClass) as RowMapper<T>
}

.

mvysny commented 4 years ago

Hi, thank you for letting me know, that's a great idea!

I wonder what would be the best way to add support for this.

The KtDao (I would suggest KDao) is excellent idea since we already have KEntity. However this way of implementation would add a direct dependency on kotlin-reflect jar which is a whopping 3mb library. We could still do it though, and then we can have the developer to decide whether to use just Dao or KDao.

Alternatively I wonder whether we can take advantage of the Jdbi plugin machinery. For example the KotlinMapper could simply be activated by calling Jdbi.installPlugins(); however then jdbi-orm would have to stop forcing Dao to use FieldMapper... which is probably not a good idea since the entire orm part depends on having fields.

I'm kinda sharing my thoughts here, trying to brainstorm, not sure which way is better. Please share your thoughts as well...