Re: JDBC 4 Compliance
| От | Kevin Wooten |
|---|---|
| Тема | Re: JDBC 4 Compliance |
| Дата | |
| Msg-id | 9C4E6298-527E-4142-ACD0-0015FFBA7B5F@me.com обсуждение исходный текст |
| Ответ на | Re: JDBC 4 Compliance (Dave Cramer <pg@fastcrypt.com>) |
| Ответы |
Re: JDBC 4 Compliance
(Gavin Flower <GavinFlower@archidevsys.co.nz>)
Re: JDBC 4 Compliance (Heikki Linnakangas <hlinnakangas@vmware.com>) |
| Список | pgsql-jdbc |
On Jun 26, 2013, at 3:44 PM, Dave Cramer <pg@fastcrypt.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.
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) ?
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.
On Wed, Jun 26, 2013 at 6:29 PM, Marc G. Fournier <scrappy@hub.org> wrote: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?On 2013-06-26, at 15:15 , Gavin Flower <GavinFlower@archidevsys.co.nz> wrote:On 27/06/13 09:45, Stephen Nelson wrote:How about, when Kevin's driver is ready: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
- recommending the existing driver for JDBC3 and earlier
- and Kevin's driver for JDBC4 and greater?
В списке pgsql-jdbc по дате отправления: