Example of a Flow-based JDBC API

Philippe Marschall pm at netcetera.ch
Wed Oct 25 15:13:22 UTC 2017

On 25.10.17 16:06, Douglas Surber wrote:
> The goal of JDBC was to expose the underlying database. Unfortunately, JDBC adds a bunch of abstraction on top of the database that greatly complicates any implementation. These complications make drivers, bigger, slower, and less reliable. With ADBA we have tried to eliminate everything that is not strictly necessary to expose the underlying database with a fully async API. Application developers and library developers are of equal importance but with the caveat that the spec not require a “smart” implementation. A thin implementation will be faster and more transparent than an implementation that requires a neural network to implement.
> In all honestly, I would say that the needs of the implementer are given priority. If the resulting API does not provide a feature that app developers need that is an opportunity for library developers. If the API does not expose a database capability that the target app needs, that is a limitation in the API. A small, transparent API makes the library developers’ job easier. Fast implementations, which are enabled by a small, transparent API, make everyone happier.
> [Note: the above strongly suggests that POJO support is superfluous and should be removed.]

I agree with all of these points including the last one. I would also 
like to add that a simpler, smaller API reduces the chance of 
implementation bugs and user frustration due to incomplete implementations.
Somewhat OT, to the informed eye (mine) OpenGL / Direct3D / Metal seem 
to take a similar route.


More information about the jdbc-spec-discuss mailing list