Re: JDBC 4 Compliance

On 27/06/13 11:57, Kevin Wooten wrote:
> On Jun 26, 2013, at 3:44 PM, Dave Cramer <pg(at)fastcrypt(dot)com
> <mailto:pg(at)fastcrypt(dot)com>> wrote:
>
>> Well I'm curious about a few things.
>>
>> 1) I just tried to build it, given I have no idea how it's not
>> surprising it failed to build. But there are no clear instructions on
>> how to build it.
>
> It's a maven build 'mvn package' should suffice. About 4 or 5 other
> people have contributed in some way and nobody has yet run into issues
> building the project. You are correct there isn't much documentation
> for anything as I am the only regular contributor it hasn't been
> necessary. On the github page there is a link to a snapshot release
> build for people to download and try (a single jar).
>
>> 2) it appears to pull in at least a few other jars, how big is it
>> when it's built? I personally use this on an embedded system where
>> size matters
>
> It only uses Netty for async i/o and Guava for utils (which can be
> removed). Currently the jar is built using the maven assembly plugin
> and produces a large jar because it pulls all of Netty and Guava into
> it; which is 3.8MB. Netty and Guava combine to contribute over 3MB
> of that size but the necessary bits of both projects are small.
> Switching from the maven assembly plugin to the maven shade plugin
> would reduce the size dramatically as it only pulls in the used class
> files. My best guess would be that it ends up around 700k or so.
> Given that the current driver is around 580k it shouldn't be that
> much different in the final version.
>
>> 3) It's my understanding that there will be resistance by larger
>> consumers to using external jars even if they are built into a single
>> jar.
>
> I don't care to get into this discussion again. I'll just say this…
> Netty is one of the few well respected async i/o libraries out there.
> Synchronous i/o is very hard to get right without a framework and
> asynchronous i/o is downright impossible. The current driver doesn't
> use async i/o and has to program around deadlocks/stalls related to
> it's synchronous i/o approach; and according to the current code
> comments doesn't seem to be completely protected against them. For
> these reasons, and the added benefits of supporting asynchronous
> notifications from the server make using a library a no-brainer.
>
>> 4) as it appears to only target one JDBC version what is the plan to
>> deal with other versions without using abstract classes like the
>> current jar, and if so how is that any better ?
>
> To support other JDBC versions I plan to use a maven java preprocessor
> plugin rather than the abstract/concrete class approach which make the
> code very to get introduced to.
>
>> 5) does it support all current versions of postgresql (ie back to 8.4) ?
>
> No. It was written knowing it's adoption would take time and as such I
> wrote it specifically for 9.2+.
>
>>
>> Lastly, I've never heard of an open source project where a bunch of
>> totally new people come in and propose forking the project without
>> any prior commitment to the project ?
>>
>> Why is there a big desire to drop the existing code base just to
>> support a few new very unused features (I'm presuming this because
>> there aren't that many requests for them) ?
>>
>
> I believe this speaks to the larger point that is at discussion here.
> A number of people are/were enthusiastic to help out with the
> mainstream driver by adding support for new features in PostgreSQL
> itself and bringing the driver up to date with regards to JDBC and
> other spec. conformance. Due to the issues and perceptions, that I
> and others, laid out at the opening of this thread it seems a number
> of people think this project is moving at too slow a pace. It also
> seems that a number of people think that the project could move
> forward faster by not specifically tying new development to the
> mainstream codebase.
>
> Alas, as we discuss this, it's becoming obvious that point I've been
> trying to make is somewhat failing on deaf ears. The current driver
> is a hinderance to people who want to use the new and interesting
> features of PostgreSQL. In my example, UDT's are well supported, and
> have been for years, in both PostgreSQL and JDBC but the driver has
> completely ignored them for years as well. As a person who has
> implemented these new features I can tell you a major overhaul in core
> is required to add these features properly. All I've heard in
> response is "don't touch it, it's stable!". So, I supposed you'll
> continue by band aiding it yet again; adding just enough code to claim
> some level of conformance and leave it in a state extremely far behind
> the server itself.
>
> I want to add one last example to further my point. You asked "Why is
> there a big desire to drop the existing code base just to support a
> few new very unused features?". It's not just to support some unused
> features. Java 6/JDBC 4 has been EOL'd by Oracle and this driver
> hasn't even bothered to support the Java 7/JDBC 4.1 spec. That's the
> whole reason this thread got started. Somebody was looking for a
> feature the Java documentation clearly said should be there and could
> not find it. Confusion ensued and now here we are. That, to me,
> speaks volumes about the lethargic pace of this project.
>
> My apologies for joining the discussion and especially for my above
> rant. I never intended to disrupt this project as it appears you
> believe it has. Actually, I intended to come here and help out in an
> impactful way. I wanted a driver that unlocks all the potential of
> the server that I prefer and instead of complaining, I chose to do
> something about it. At this point it sounds like my best bet is to
> quietly return to my work on that project and stop causing a
> disruption around here. I will say that I welcome any and all people
> who would like to join me in my effort. It seems the political
> climate is just not there for joining forces.
>
>>
>>
>> Dave Cramer
>>
>> dave.cramer(at)credativ(dot)ca
>> http://www.credativ.ca <http://www.credativ.ca/>
>>
>>
>> On Wed, Jun 26, 2013 at 6:29 PM, Marc G. Fournier <scrappy(at)hub(dot)org
>> <mailto:scrappy(at)hub(dot)org>> wrote:
>>
>>
>> On 2013-06-26, at 15:15 , Gavin Flower
>> <GavinFlower(at)archidevsys(dot)co(dot)nz
>> <mailto:GavinFlower(at)archidevsys(dot)co(dot)nz>> wrote:
>>
>>> On 27/06/13 09:45, Stephen Nelson wrote:
>>>> In my view the driver has already been forked by Kevin Wooten
>>>> so it's more of a case of will it be an official fork or not? I
>>>> think it would be a good idea to harness the enthusiasm from
>>>> the contributors to the newer driver. However I think it would
>>>> be a shame and a mistake to throw away the work that has gone
>>>> into the stable driver. If it's not feasible to merge the code
>>>> of both drivers I do think it would be useful to share what can
>>>> be - particularly the functional tests.
>>>>
>>>> If it is decided to promote both drivers as official projects I
>>>> think, for the benefit of the users confused about the choice,
>>>> that the newer driver be labelled as a beta until such time as
>>>> everyone is convinced in its stability and functionality, that
>>>> it is pushed as the current driver and then the older one can
>>>> become legacy.
>>>>
>>>> My interest in the project has mainly been around getting the
>>>> jars automatically uploaded to Maven. I'm interested in
>>>> reviewing driver patches but I don't have the knowledge of the
>>>> protocol at the moment to provide any useful feedback other
>>>> than obvious things. I would like to experiment with an
>>>> alternative build system called Gradle and get continuous
>>>> integration and deployment sorted out so that upon check-in the
>>>> driver is built on a variety of platforms, tested on a variety
>>>> of servers and automatically deployed to Maven central as well
>>>> as the website. My time is a bit variable with kids/work/life
>>>> taking a big chunk of it so I would like to collaborate with
>>>> people on the project.
>>>>
>>>> Cheers,
>>>>
>>>> Stephen
>>> How about, when Kevin's driver is ready:
>>>
>>> 1. recommending the existing driver for JDBC3 and earlier
>>> 2. and Kevin's driver for JDBC4 and greater?
>>>
>>
>> Why not just create a 'pre-JDBC4 branch for the current official
>> one and import Kevin's as JDBC4, for going forward? What I've
>> read seems to indicate a reluctance to make a whole whack of
>> changes on the current code, so putting it over to a branch
>> shouldn't cause to much angst, should it?
>>
>>
>>
>
Kevin, while I can give you only moral support - I would really like you
to continue!

Cheers,
Gavin