64 ms·

I definitely agree with "no Fitnesse", sorry, FitNesse, ugh, and likewise, no Selenium. Not so much for the slowness. In the case of FitNesse (ugh), it's the W

I definitely agree with "no Fitnesse", sorry, FitNesse, ugh, and likewise, no Selenium. Not so much for the slowness. In the case of FitNesse (ugh), it's the Wiki -> Java impedance mismatch, and in terms of Selenium, it's the brittleness. Move an element, watch Selenium tests generated by a QA's browser plugin break. I rather loathe Hibernate these days (JDBI is my favourite atm), and well, Tomcat feels rather legacy. But I guess that's the advantage of 9 years of advances. > you can use the maven structure and produce maven artifacts with your build but use a different tool (Make, sbt, buildr, ant etc) Omg, no, sbt is far, far, far, worse. Ditto ant. Not sure if buildr is still a thing? Looks like the last release was 2017. And as for make, how would you even integrate various Maven plugins into it?

cies 6y ago
> JDBI is my favourite atm Tried JOOQ? There's generator overhead on db schema changes, and it adds lots of classes to your classpath (but this could be inside a precompiled library). I guess it adds some build time, not sure how much though (for sure more than JDBI). But that sweet typesafety and auto-complete is worth something.
karmakaze 6y ago
Interesting choice of JDBI. I was working on an SQL-friendly ORM[0] also due to distaste with Hibernate/JPQL and chose JDBI, not because it was great in any way but it did what I needed and not much else. What influenced your choice and were there any close runner-ups? [0] https://github.com/karmakaze/safeql https://github.com/karmakaze/safeql
- asadawadia 6y ago
  have you looked into ktorm?
  - karmakaze 6y ago
    I wasn't looking at Kotlin libraries, but this one seems to be very close to what I was going for. Specifically about being able to compose queries in a bottom-up fashion like the UnionAll example with subqueries. It's unfortunate that they chose to use .filter (.where would have been clearer) for DB executed conditions as well as post-fetch sequence filtering.
- EdwardDiego 6y ago
  For us, it was basically about using direct SQL to avoid the ORM / SQL mismatch, while still having a (relatively) straightforward way to turn rows into POJOs. I mean, not as easy as just annotating some attributes of a class for Hibernate, but being able to specify the SQL itself was what sold me on it. I guess it's not much different to Spring's JdbcTemplate etc. in that regard, but it came with minimal dependency baggage. I do quite like Jdbi's SqlObject API, wherein you annotate a interface's methods with SQL (and a bunch of other annotations if you're getting fancy) which abstracts the boilerplate away to a large extent. I use this quite often for integration testing where there's an embedded PG instance and you need a straightforward way to populate it with expected data. Where it really shined though, was in stuff that is trivial in SQL, but hard in DSLs, like doing a batch upsert (or as PG calls it, INSERT ... ON CONFLICT DO UPDATE...) was trivial in Jdbi compared to Hibernate etc. Just because we weren't relying on some DSL to generate the necessary SQL. Also, Jdbi integrates reasonably nicely with Flyway schema migrations.
  - karmakaze 6y ago
    Thanks for sharing that. I completely agree with your assessments. My motivation was similar, mainly fighting with Hibernate/JPQL and wanting something simpler that was structured the natural bottom-up way an SQL query would be written. Another thing that ORMs don't do well is avoiding N+1 queries when you're already starting with N of something that have associations. I started SafeQL to see where it could go but have yet to do any code generation which is what it needs to be usably convenient. Also haven't ventured much into complex UPDATEs or UPSERTs.

cies 6y ago

> JDBI is my favourite atm Tried JOOQ? There's generator overhead on db schema changes, and it adds lots of classes to your classpath (but this could be inside a precompiled library). I guess it adds some build time, not sure how much though (for sure more than JDBI). But that sweet typesafety and auto-complete is worth something.

karmakaze 6y ago

Interesting choice of JDBI. I was working on an SQL-friendly ORM[0] also due to distaste with Hibernate/JPQL and chose JDBI, not because it was great in any way but it did what I needed and not much else. What influenced your choice and were there any close runner-ups? [0] https://github.com/karmakaze/safeql https://github.com/karmakaze/safeql

asadawadia 6y ago
have you looked into ktorm?
- karmakaze 6y ago
  I wasn't looking at Kotlin libraries, but this one seems to be very close to what I was going for. Specifically about being able to compose queries in a bottom-up fashion like the UnionAll example with subqueries. It's unfortunate that they chose to use .filter (.where would have been clearer) for DB executed conditions as well as post-fetch sequence filtering.
EdwardDiego 6y ago
For us, it was basically about using direct SQL to avoid the ORM / SQL mismatch, while still having a (relatively) straightforward way to turn rows into POJOs. I mean, not as easy as just annotating some attributes of a class for Hibernate, but being able to specify the SQL itself was what sold me on it. I guess it's not much different to Spring's JdbcTemplate etc. in that regard, but it came with minimal dependency baggage. I do quite like Jdbi's SqlObject API, wherein you annotate a interface's methods with SQL (and a bunch of other annotations if you're getting fancy) which abstracts the boilerplate away to a large extent. I use this quite often for integration testing where there's an embedded PG instance and you need a straightforward way to populate it with expected data. Where it really shined though, was in stuff that is trivial in SQL, but hard in DSLs, like doing a batch upsert (or as PG calls it, INSERT ... ON CONFLICT DO UPDATE...) was trivial in Jdbi compared to Hibernate etc. Just because we weren't relying on some DSL to generate the necessary SQL. Also, Jdbi integrates reasonably nicely with Flyway schema migrations.
- karmakaze 6y ago
  Thanks for sharing that. I completely agree with your assessments. My motivation was similar, mainly fighting with Hibernate/JPQL and wanting something simpler that was structured the natural bottom-up way an SQL query would be written. Another thing that ORMs don't do well is avoiding N+1 queries when you're already starting with N of something that have associations. I started SafeQL to see where it could go but have yet to do any code generation which is what it needs to be usably convenient. Also haven't ventured much into complex UPDATEs or UPSERTs.