Re: JDBC 4 Compliance

<div>På torsdag 27. juni 2013 kl. 02:20:17, skrev Gavin Flower <<a href="mailto:GavinFlower@archidevsys.co.nz"
target="_blank">GavinFlower@archidevsys.co.nz</a>>:</div><blockquotestyle="border-left: 1px solid rgb(204, 204,
204);margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="moz-cite-prefix">On 27/06/13 11:57, Kevin Wooten
wrote:</div><blockquotecite="mid:9C4E6298-527E-4142-ACD0-0015FFBA7B5F@me.com" type="cite"><div><div>On Jun 26, 2013, at
3:44PM, Dave Cramer <<a href="mailto:pg@fastcrypt.com" moz-do-not-send="true"
target="_blank">pg@fastcrypt.com</a>>wrote:</div>   <blockquote type="cite"><div dir="ltr">Well I'm curious about a
fewthings. <div> </div><div style="">1) I just tried to build it, given I have no idea how it's not surprising it
failedto build. But there are no clear instructions on how to build it.</div></div></blockquote><div> </div> It's a
mavenbuild 'mvn package' should suffice.  About 4 or 5 other people have contributed in some way and nobody has yet run
intoissues building the project.  You are correct there isn't much documentation for anything as I am the only regular
contributorit hasn't been necessary.  On the github page there is a link to a snapshot release build for people to
downloadand try (a single jar).<br />   <blockquote type="cite"><div dir="ltr"><div style="">2) it appears to pull in
atleast a few other jars, how big is it when it's built? I personally use this on an embedded system where size
matters</div></div></blockquote><div> </div><div>Itonly 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
Nettyand Guava into it; which is 3.8MB.   Netty and Guava combine to contribute over 3MB of that size but the necessary
bitsof both projects are small.  Switching from the maven assembly plugin to the maven shade plugin would reduce the
sizedramatically as it only pulls in the used class files.  My best guess would be that it ends up around 700k or so.
 Giventhat the current driver is around 580k it shouldn't be that much different in the final version.</div>  
<blockquotetype="cite"><div dir="ltr"><div style="">3) It's my understanding that there will be resistance by larger
consumersto using external jars even if they are built into a single jar.</div></div></blockquote><div> </div><div>I
don'tcare to get into this discussion again.  I'll just say this… Netty is one of the few well respected async i/o
librariesout 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
synchronousi/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
librarya no-brainer.</div>   <blockquote type="cite"><div dir="ltr"><div style=""> </div><div style="">4) as it appears
toonly target one JDBC version what is the plan to deal with other versions without using abstract classes like the
currentjar, and if so how is that any better ?</div></div></blockquote><div> </div><div>To support other JDBC versions
Iplan to use a maven java preprocessor plugin rather than the abstract/concrete class approach which make the code very
toget introduced to.</div>   <blockquote type="cite"><div dir="ltr"><div style="">5) does it support all current
versionsof postgresql (ie back to 8.4) ?</div></div></blockquote><div> </div> No. It was written knowing it's adoption
wouldtake time and as such I wrote it specifically for 9.2+.</div><div> </div><div><blockquote type="cite"><div
dir="ltr"><divstyle=""> </div><div style="">Lastly, I've never heard of an open source project where a bunch of totally
newpeople come in and propose forking the project without any prior commitment to the project
?</div></div></blockquote><blockquotetype="cite"><div dir="ltr"><div style=""> </div><div style="">Why is there a big
desireto drop the existing code base just to support a few new very unused features (I'm presuming this because there
aren'tthat many requests for them) ?</div><div style=""> </div></div></blockquote><div> </div><div><div>I believe this
speaksto the larger point that is at discussion here.  A number of people are/were enthusiastic to help out with the
mainstreamdriver by adding support for new features in PostgreSQL itself and bringing the driver up to date with
regardsto JDBC and other spec. conformance.  Due to the issues  and perceptions, that I and others, laid out at the
openingof this thread it seems a number of people think this project is moving at too slow a pace.  It also seems that
anumber of people think that the project could move forward faster by not specifically tying new development to the
mainstreamcodebase.</div><div> </div><div>Alas, as we discuss this, it's becoming obvious that point I've been trying
tomake is somewhat failing on deaf ears.  The current driver is a hinderance to people who want to use the new and
interestingfeatures of PostgreSQL.   In my example, UDT's are well supported, and have been for years, in both
PostgreSQLand JDBC but the driver has completely ignored them for years as well.   As a person who has implemented
thesenew features I can tell you a major overhaul in core is required to add these features properly.  All I've heard
inresponse is "don't touch it, it's stable!".  So, I supposed you'll continue by band aiding it yet again; adding just
enoughcode to claim some level of conformance and leave it in a state extremely far behind the server
itself.</div><div> </div><div>Iwant to add one last example to further my point.  You asked "Why is there a big desire
todrop 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
clearlysaid should be there and could not find it.  Confusion ensued and now here we are.  That, to me, speaks volumes
aboutthe lethargic pace of this project.</div><div> </div><div>My apologies for joining the discussion and especially
formy above rant.  I never intended to disrupt this project as it appears you believe it has.  Actually, I intended to
comehere and help out in an impactful way.  I wanted a driver that unlocks all the potential of the server that I
preferand instead of complaining, I chose to do something about it.   At this point it sounds like my best bet is to
quietlyreturn to my work on that project and stop causing a disruption around here.  I will say that I welcome any and
allpeople who would like to join me in my effort.  It seems the political climate is just not there for joining
forces.</div><div> </div></div><blockquotetype="cite"><div dir="ltr"><div style=""> </div></div><div
class="gmail_extra"> <div>Dave Cramer<br /><br /> dave.cramer(at)credativ(dot)ca<br /><a href="http://www.credativ.ca/"
moz-do-not-send="true"target="_blank">http://www.credativ.ca</a></div>   <div class="gmail_quote">On Wed, Jun 26, 2013
at6:29 PM, Marc G. Fournier <span dir="ltr"><<a href="mailto:scrappy@hub.org" moz-do-not-send="true"
target="_blank">scrappy@hub.org</a>></span>wrote: <blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px#ccc solid;padding-left:1ex"><div style="word-wrap:break-word">  <div><div class="im"><div>On
2013-06-26,at 15:15 , Gavin Flower <<a href="mailto:GavinFlower@archidevsys.co.nz" moz-do-not-send="true"
target="_blank">GavinFlower@archidevsys.co.nz</a>>wrote:</div>   <blockquote type="cite"><div bgcolor="#FFFFFF"
text="#000000"><div>On27/06/13 09:45, Stephen Nelson wrote:</div><blockquote type="cite"><div dir="ltr"><div
class="gmail_extra">Inmy view the driver has already been forked by Kevin Wooten so it's more of a case of will it be
anofficial 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.
Ifit's not feasible to merge the code of both drivers I do think it would be useful to share what can be - particularly
thefunctional tests.</div><div class="gmail_extra"> </div><div class="gmail_extra">If it is decided to promote both
driversas official projects I think, for the benefit of the users confused about the choice, that the newer driver be
labelledas a beta until such time as everyone is convinced in its stability and functionality, that it is pushed as the
currentdriver and then the older one can become legacy.</div><div class="gmail_extra"> </div><div
class="gmail_extra">Myinterest in the project has mainly been around getting the jars automatically uploaded to Maven.
I'minterested in reviewing driver patches but I don't have the knowledge of the protocol at the moment to provide any
usefulfeedback other than obvious things. I would like to experiment with an alternative build system called Gradle and
getcontinuous 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
abit variable with kids/work/life taking a big chunk of it so I would like to collaborate with people on the
project. </div><divclass="gmail_extra"> </div><div class="gmail_extra">Cheers,</div><div
class="gmail_extra"> </div><divclass="gmail_extra">Stephen</div></div></blockquote><font size="-1">How about</font>,
whenKevin's driver is ready: <ol><li>recommending the existing driver for JDBC3 and earlier<li>and Kevin's driver for
JDBC4and greater?</ol></div></blockquote><div> </div></div> Why not just create a 'pre-JDBC4 branch for the current
officialone and import Kevin's as JDBC4, for going forward?  What I've read seems to indicate a reluctance to make a
wholewhack of changes on the current code, so putting it over to a branch shouldn't cause to much angst, should
it?</div><div> </div><div> </div></div></blockquote></div></div></blockquote></div></blockquote><fontsize="-1"><font
size="-1"><fontsize="-1">Kevin, w</font>hile </font>I can give you only moral support</font> - I would really like you
tocontinue!</blockquote><div> </div><div>+1 for Kevin's driver and hopefully an actively developed
driver.</div><div> </div><div>Isee Kevin's driver also supports Connection.createBlob, which is handy for EclipseLink
users(which I'm planning on migrating to, from Hibernate) as EclipseLink doesn't offer a blog-helper util for creating
blobs,like Hibernate does.</div><div> </div><div>Kevin; I have quite a large project and I'm willing to give your
drivera spin. Will give feedback soon.</div><div> </div><div class="origo-email-signature">--<br /> Andreas Joseph
Krogh<andreak@officenet.no>      mob: +47 909 56 963<br /> Senior Software Developer / CTO - OfficeNet AS -
http://www.officenet.no<br/> Public key: http://home.officenet.no/~andreak/public_key.asc</div><div> </div>