Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide KotlinMapper as rowMapper for Dao/DaoOfAny #14

Open
stapel opened this issue May 28, 2020 · 1 comment
Open

Provide KotlinMapper as rowMapper for Dao/DaoOfAny #14

stapel opened this issue May 28, 2020 · 1 comment
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@stapel
Copy link
Contributor

stapel commented May 28, 2020

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 mvysny self-assigned this May 29, 2020
@mvysny
Copy link
Owner

mvysny commented May 29, 2020

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...

@mvysny mvysny added enhancement New feature or request question Further information is requested labels May 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants