You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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...
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:
.
The text was updated successfully, but these errors were encountered: