[agentgt]

I too wrote my own crappy (anti)ORM-like library a few years back as well https://github.com/agentgt/jirm . The most notably difference from other libraries was focusing on immutable objects and embracing real SQL (not a DSL like jOOQ) using a better SQL template language (instead of the JDBC '?') https://github.com/agentgt/jirm/blob/master/jirm-core/README... . I guess the closest library would be MyBatis.

The problem with writing your own library is the massive and continuous support that is required. This is where I eventually gave in and used jOOQ. Its an extremely well maintained and documented library. People complain about it not being completely opensource but neither is intellij so I don't have a problem (as well I also only use opensource databases).

[eropple]

> Its an extremely well maintained and documented library.

I find its documentation coverage to be good but its quality to be lacking, being mostly written by non-native English speakers. Which is fine, if there are good examples and tests to use--but jOOQ actually deleted unit tests from the open-source release of the library (declaring them "an enterprise feature") to remove the easiest and best way to investigate the library, as well as the only unambiguous documentation the project has. ("Ask a question on our Google Group" was suggested with a straight face. Because in 2015, it's better to wait on an email than look at code, I guess.)

[vtman2002]

that is shady. bit it looks like they're still there in the git history: https://github.com/jOOQ/jOOQ/tree/fc7afb40760246153da4a2334c...

even the stuff that has been xxxed out: https://github.com/jOOQ/jOOQ/blob/63717b517fccf475089648ca3c... and it's still under the APL.

[eropple]

Yup. I ended up using the last version of them I could when I had to use jOOQ, but I didn't feel at all comfortable endorsing the behavior going forward.

[vtman2002]

Massive and continual support? That has not been my experience. Even after leaving TS, it looks like Lynch (who took over internal support: https://github.com/salynch/DKO) has make only a dozen or so commits. SQL is not a fast-changing target.

[agentgt]

Well with out extensively using your library I can only guess a couples of things must be true for not needing maintenance:

* Your library has a very limited set of capabilities

* Your library is not extensively tested on all supported databases all the time and thus bugs are not being found.

Also I find the claim of streaming support sort of disingenuous or at least the word streaming misleading. Real streaming that is required for reactive like programming (ie reactive-streams) is not supported by the JDBC drivers because operations are bound to thread/connection. If you are just talking about Iterator like streaming than you do realize you are at the mercy of the database driver itself. For example Postgres and many other databases will almost always preload a certain amount of the ResultSet regardless (and in my experience a rather large ammount).

[vtman2002]

Correct, iterator-based-streaming, as java6 was the norm when I wrote this. And yes, you're obviously at the mercy of your JDBC driver. Though I'd argue if your results are fitting into PostgreSQL's default preload size (whatever it may be) you don't really need to worry about it. But I promise you it does stream. (TS is not known for it's small datasets...)

[agentgt]

I think you understand this but its more than just handling large datasets memory friendly. True streaming would allow you to keep your connection pool happy. If you stream a large dataset you have to keep the connection open (lets say for a web request which is the common case) and you can't reuse that connection till you retrieve the entire dataset (or I guess read a subset and stop). For batch processing this ok but for web requests this is generally not ok. Asynchronous drivers are push based and are analogous to NIO HTTP like Netty (some non-JDBC async drivers I think even use Netty). But I'm going to gather you understand that and/or either using a very sophisticated pooling technique/drivers.

So if I block too long while reading an iterator like object because the client is taking to long to read... I think you can imagine what happens. This is why so many of the JDBC wrappers (such as Spring JDBC and JDBI ) do not return iterators or at least do not advertise it as an awesome feature.

[vtman2002]

Our pooling was pretty shitty actually, but it didn't need to be fancy as 95% of our code was some sort of batch processing (as you guessed), after which the JVM terminated. But yes, highly tweaked JDBC drivers over all.

Hibernate has iterator methods, but I recall (in 2010) it still loaded the entire result set into memory, with a //TODO comment. I remember thinking "W...T...F..." I can't tell you how many -Xmx16G (or 32/64) flags I deleted...

[lukaseder]

This is because you consider DKO to be "equivalent" :)

[vtman2002]

Fair enough. I don't know enough about jOOq to claim equivalency to your baby. I just wrote DKO to scratch an itch. (That itch being Hibernate!) Fully supportive of the general pattern, and glad you're free now for open source databases. In hindsight, perhaps I should have sought out VC funding. :)

[lukaseder]

VC don't care that much about middleware anymore...