Closed mvysny closed 4 years ago
Ongoing work at branch https://github.com/mvysny/vok-orm/tree/13-move-to-jdbi
Also get rid of the Accessor infrastructure, it only created unnecessary complexity. You can always get access to the DataSource instance, both in Spring and in JavaEE.
Looks good, I've removed a lot of code and cleaned up the library quite a lot. However there are the following issues:
override id: Long
in the Data class since Entity comes from Java which doesn't have properties. Therefore you need to write private id: Long
in data class's constructor, then override getId() and setId()
which is annoying.save(boolean)
and not save()
. Potentially dangerous.companion class : Dao<Person, Long>(Person::class.java)
. Only slightly annoying.Person.findBy { Person::id eq 25 }
since Person::id
is no longer KProperty. Not really useful anyway, so this is okay.UuidEntity
now needs to use @JvmDefault
which requires the -Xjvm-default=enable
kotlin compiler arg. Only slightly annoying, you only need to do this once, and the case is pretty special anyway.However, the good news is that using entities is still as pleasant as it was before, so Person.findAll()
still works really well.
Solved 1., 2., 4., and 5. by introducing AbstractEntity into JDBI-ORM and letting every language introduce its own entity (e.g. KEntity for Kotlin).
Looks in a good shape. Still needed to do:
[x] Update README [x] Release 1.0 [x] Update https://gitlab.com/mvysny/vok-orm-playground [x] Release VoK 0.7.x with the old vok-orm
All done. A ticket for VoK-related work is here: https://github.com/mvysny/vaadin-on-kotlin/issues/40
sql2o seem to be unmaintained and dead. There are unresolved issues which are tricky to work around. I've used JDBI in my other ORM engine at https://gitlab.com/mvysny/jdbi-orm and it has been working very well so far. Maybe it's time to switch...
I could do a new major release of vok-orm which would be based not on Sql2o, but on JDBI instead, or even better on JDBI-ORM and only add Kotlin-specific bits?