Re: JDBC 4 Compliance

On Jun 24, 2013, at 2:15 PM, David Johnston <polobo(at)yahoo(dot)com> wrote:

> Dave Cramer-8 wrote
>>> 2) Maintenance Mode
>>> You can tell the code is in maintenance mode just by reading it. I won’t
>>> repeat my previous discussions about the state of the code now but there
>>> is
>>> quite obvious code rot going on as features are slapped together in the
>>> most fragile of ways. I believe that is what any project in “maintenance
>>> mode” gets; just another name for a project experiencing code rot. It
>>> seemed obvious to me, both then and now, that working within the current
>>> framework was going to take a lot longer than just rolling a new one;
>>> that
>>> comes from somebody who now has a near complete implementation of
>>> java.sql.Driver.
>>>
>
> I cannot seem to get a coherent thought going here but just some thoughts
> for everyone to consider.
>
> I think one of the biggest changes that could be made, given that the
> current driver has accumulated so much technical (and process) debt - not to
> mention the stability that it needs - would be for the PostgreSQL Global
> Development Group to become not only the maintainer of the current driver
> but also a trusted resource that PostgreSQL+Java users can rely upon to help
> them evaluate the various implementations of the JDBC driver that exist to
> meet the diverse needs of the community. It should enforce minimal
> standards by creating a black/white lists with specific details as to
> missing mandatory features or structure (i.e., licensing; timely response to
> community feedback like pull requests; etc...).
>
> The goal should be to identify one or more reference implementations for the
> current pair of JVM+PostgreSQL and assist whomever "maintains" that
> implementation. This implementation should try to strive for backward
> compatibility but implementing all the specification/database features is of
> a higher priority.
>
> As a user I would want an idea of the trade-offs between different
> implementations to aid in researching and some guidance on how to properly
> evaluate different drivers in my custom environment.
>

I think David is onto something with this strategy of freezing the current driver and starting with a fresh implementation. As a person who has familiarity with the mainstream codebase and my own implementation of the Driver this solves some of the biggest issues I see for myself.

First, trying to combine the projects at this point seems almost nonsensical since I have so much of it implemented and working well (for me at least). Also, there is such a disparity between the two code bases that I can’t imagine which parts we could actually merge. The only code I referenced from the mainstream driver was for the “meta-data” classes because the required queries were given.

Second, porting my implementation back to Java 5/6 and/or PostgreSQL servers prior to 9.2. The current driver has lots of special case code for servers and now JDK’s that have been EOL’d. My project implementation currently has none, it runs on JDK 7/JDBC 4.1 and Postgres >= 9.2. I believe there is a more elegant way to handle these cases going forward than the option used in the mainstream project of abstract/concrete classes for each JDBC version. I think JDBC differences should be handled with the maven pre-processor plugin to conditionally compile for each JDBC. Server differences can still use special case code and/or polymorphic classes to address the problem/feature at hand.

If we froze it and began using a new implementation, maybe even mine, for Java 7+ and worked toward offering it as an official alternative in the future at some point we could have the best of both worlds; a stable driver that “works the same” for people who care only about stability while we create a newer faster moving and better conforming project that will have regular stable releases in the future.

> Without a strong JDBC community the attractiveness of PostgreSQL as a
> back-end is going to stagnate. Technological innovation is needed but the
> way it is occurring right now has the downside of giving off a "fracturing"
> vibe. The programmers are not going to be able (or want) to solve that part
> of the puzzle. Ideally one of the vendors who wants to innovate on the
> driver could take some of these observations and leverage it into something
> they can earn money on (likely via consulting on things like performance -
> and other kinds of - testing).
>

This is where I was at when I began our latest project. We saw so much potential in PostgreSQL and just kept coming up with simple and elegant ways to solve some of our problems with it. Then we had a big let down when we realized that we kept bumping into the driver itself when we tried to use some of these features (UDT support was our biggest problem).

> I am likely a typical user which means that the status-quo really hasn't
> been something that I've said to myself that there is a problem. Mailing
> list traffic is pretty light and because it is in maintenance mode there
> just isn't much excitement in being noisy just to tell people you are still
> alive. Putting things into core indeed has a high barrier but that is
> because the vast majority of people simply look at the current driver as
> being canon and want their existing software to continue working the way it
> did on the last version. Thus some form of forking is going to be required
> - the question is who creates and maintains the forks and how long should
> they survive.
>
> Sorry for the rambling especially since I'm not currently planning to
> actually act on my own advice but hopefully people will find some value in
> my perspective.
>
> David J.
>
>
>
>
>
>
> --
> View this message in context: http://postgresql.1045698.n5.nabble.com/JDBC-4-Compliance-tp5760468p5760763.html
> Sent from the PostgreSQL - jdbc mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc