search

mvysny / vok-orm

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

Move from sql2o to JDBI #13

Closed mvysny closed 5 years ago

mvysny commented 5 years ago

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?

mvysny commented 5 years ago

Ongoing work at branch https://github.com/mvysny/vok-orm/tree/13-move-to-jdbi

mvysny commented 5 years ago

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.

mvysny commented 5 years ago

Looks good, I've removed a lot of code and cleaned up the library quite a lot. However there are the following issues:

  1. You can't use 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.
  2. Since Java doesn't have default values, there are now two save() and two create() methods, and you need to be careful to override the save(boolean) and not save(). Potentially dangerous.
  3. Since Dao is now class and not an interface, you need to write companion class : Dao<Person, Long>(Person::class.java). Only slightly annoying.
  4. You can't write Person.findBy { Person::id eq 25 } since Person::id is no longer KProperty. Not really useful anyway, so this is okay.
  5. The 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.

mvysny commented 5 years ago

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

mvysny commented 5 years ago

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

mvysny commented 5 years ago

All done. A ticket for VoK-related work is here: https://github.com/mvysny/vaadin-on-kotlin/issues/40