Обсуждение: pgjdbc-ng
Just wanted to update everybody on the happenings with the “ng” driver… Thanks to the work of Jesper Pedersen we now have Datasource support. This marks the final feature required for JDBC 4.1compliance. Although I am sure there are defects in our support, the driver is now feature complete with regard to thespec. Version 0.3 Notable Changes: * Datasource/XADatasource support (thanks to Jesper Pedersen) * Prepared Statement Cache (thanks to Brett Woolridge) * SQL Parsing Cache (thanks to Brett Woolridge) * Support for geometric types As always we’d love for you to try the driver out and help us locate any defects and deficiencies in it’s support. Project: https://github.com/impossibl/pgjdbc-ng Thanks, Kevin Wooten
Hi Kevin, On Tue, Feb 25, 2014 at 1:12 AM, Kevin Wooten <kdubb@me.com> wrote: > Just wanted to update everybody on the happenings with the "ng" driver... Thanks for the heads up. I will try it on the apps we currently have under development. They are based on Hibernate 4.3.x and PostgreSQL 9.2. Is PostgreSQL 9.2 a strong requirement or only necessary for advanced features? Our biggest app is using 9.1 and it will probably stay that way for quite a long time. As it's the most interesting app we have here (complexity and load), I think it could be nice to see how it goes with this app, too. Thanks for your work. -- Guillaume
On Tue, Feb 25, 2014 at 3:20 PM, Guillaume Smet
<guillaume.smet@gmail.com> wrote:
> Is PostgreSQL 9.2 a strong requirement or only necessary for advanced
> features?
Considering I have the following exception at startup:
[2014-02-25 15:44:27,711] ERROR - ConnectionPool - -
Unable to create initial connections of pool.
com.impossibl.postgres.jdbc.PGSQLSimpleException: Connection Error:
relation "pg_catalog.pg_range" does not exist
at com.impossibl.postgres.jdbc.ErrorUtils.makeSQLException(ErrorUtils.java:159)
at com.impossibl.postgres.jdbc.ConnectionUtil.createConnection(ConnectionUtil.java:181)
9.2 looks like a strong requirement.
Too bad.
--
Guillaume
On 02/25/2014 04:49 PM, Guillaume Smet wrote: > On Tue, Feb 25, 2014 at 3:20 PM, Guillaume Smet > <guillaume.smet@gmail.com> wrote: >> Is PostgreSQL 9.2 a strong requirement or only necessary for advanced >> features? > > Considering I have the following exception at startup: > [2014-02-25 15:44:27,711] ERROR - ConnectionPool - - > Unable to create initial connections of pool. > com.impossibl.postgres.jdbc.PGSQLSimpleException: Connection Error: > relation "pg_catalog.pg_range" does not exist > at com.impossibl.postgres.jdbc.ErrorUtils.makeSQLException(ErrorUtils.java:159) > at com.impossibl.postgres.jdbc.ConnectionUtil.createConnection(ConnectionUtil.java:181) > 9.2 looks like a strong requirement. That should be easy to fix. Looking at PGtype, where the query is coming from, all you need to do is add another version of the query without the reference to pg_range. The logic for sending a different version of the query depending on the server version is already there. - Heikki
Hi Heikki, On Tue, Feb 25, 2014 at 4:01 PM, Heikki Linnakangas <hlinnakangas@vmware.com> wrote: > That should be easy to fix. Looking at PGtype, where the query is coming > from, all you need to do is add another version of the query without the > reference to pg_range. The logic for sending a different version of the > query depending on the server version is already there. I haven't taken a look at the code because IIRC they didn't want to bloat the driver with support for old versions. From my point of view, 9.1 would be the perfect starting point as it's still widely in production and it will probably stay that way for a while. But there may be good reasons to not support it. If support for 9.1 is something they are interested in, we can take a look at it. Just ping me. -- Guillaume
I will look into support for 9.1. I started with 9.2 purely because it was the latest release at the time and I thoughtit would take a whole lot longer to get to where we are at. On Feb 25, 2014, at 8:12 AM, Guillaume Smet <guillaume.smet@gmail.com> wrote: > Hi Heikki, > > On Tue, Feb 25, 2014 at 4:01 PM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> That should be easy to fix. Looking at PGtype, where the query is coming >> from, all you need to do is add another version of the query without the >> reference to pg_range. The logic for sending a different version of the >> query depending on the server version is already there. > > I haven't taken a look at the code because IIRC they didn't want to > bloat the driver with support for old versions. > > From my point of view, 9.1 would be the perfect starting point as it's > still widely in production and it will probably stay that way for a > while. But there may be good reasons to not support it. > > If support for 9.1 is something they are interested in, we can take a > look at it. Just ping me. > > -- > Guillaume
Guillaume, I committed support for version 9.1 server. It seems it was almost as easy as Heikki suggested. Although, to test you currentlyneed to build the driver from the main develop branch. If you can find the time please build and try it, then report back Kevin On Feb 25, 2014, at 8:45 AM, Kevin Wooten <kdubb@me.com> wrote: > I will look into support for 9.1. I started with 9.2 purely because it was the latest release at the time and I thoughtit would take a whole lot longer to get to where we are at. > > On Feb 25, 2014, at 8:12 AM, Guillaume Smet <guillaume.smet@gmail.com> wrote: > >> Hi Heikki, >> >> On Tue, Feb 25, 2014 at 4:01 PM, Heikki Linnakangas >> <hlinnakangas@vmware.com> wrote: >>> That should be easy to fix. Looking at PGtype, where the query is coming >>> from, all you need to do is add another version of the query without the >>> reference to pg_range. The logic for sending a different version of the >>> query depending on the server version is already there. >> >> I haven't taken a look at the code because IIRC they didn't want to >> bloat the driver with support for old versions. >> >> From my point of view, 9.1 would be the perfect starting point as it's >> still widely in production and it will probably stay that way for a >> while. But there may be good reasons to not support it. >> >> If support for 9.1 is something they are interested in, we can take a >> look at it. Just ping me. >> >> -- >> Guillaume > > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc
Hi Kevin,
On Wed, Feb 26, 2014 at 7:10 AM, Kevin Wooten <kdubb@me.com> wrote:
> I committed support for version 9.1 server. It seems it was almost as easy as Heikki suggested. Although, to test
youcurrently need to build the driver from the main develop branch.
1/ About error handling in the initialization phase
I took a shot at it yesterday evening too but couldn't get the tests
to run on my laptop. I didn't have a useful exception, just the fact
that it hits the throw new IOException("invalid utility query"); in
BasicContext line 397 for some reason, probably because the query
wasn't executed correctly.
I checked what you did and it's a little bit different from what I did
(I had a "null as rng..." and you simply don't have it) so the error
is on my part. But I still think there's something weird in the error
management: I should have got something more precise, shouldn't I?
Do you think I should take a look at it and try to put together a pull
request or is it normal for you?
2/ Tests failing on my laptop once I got what you commited:
2.1 DatabaseMetaDataTest.testEscaping
com.impossibl.postgres.jdbc.PGSQLSimpleException: LIKE pattern must
not end with escape character
at com.impossibl.postgres.jdbc.ErrorUtils.makeSQLException(ErrorUtils.java:159)
at com.impossibl.postgres.jdbc.ErrorUtils.makeSQLException(ErrorUtils.java:136)
at com.impossibl.postgres.jdbc.PGConnectionImpl.execute(PGConnectionImpl.java:432)
at com.impossibl.postgres.jdbc.PGStatement.executeStatement(PGStatement.java:372)
at com.impossibl.postgres.jdbc.PGPreparedStatement.execute(PGPreparedStatement.java:233)
at com.impossibl.postgres.jdbc.PGPreparedStatement.executeQuery(PGPreparedStatement.java:249)
at com.impossibl.postgres.jdbc.PGDatabaseMetaData.execForResultSet(PGDatabaseMetaData.java:112)
at com.impossibl.postgres.jdbc.PGDatabaseMetaData.getTables(PGDatabaseMetaData.java:1047)
at com.impossibl.postgres.jdbc.DatabaseMetaDataTest.testEscaping(DatabaseMetaDataTest.java:777)
2.2 ServerDisconnectTest is failing (but I don't think I can send
signal to the server with this user so it should be fine)
java.lang.AssertionError: Expected exception: java.sql.SQLException
2.3 I think the tests are timezone dependant:
java.lang.AssertionError: expected:<09:30:30> but was:<08:30:30>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:743)
at org.junit.Assert.assertEquals(Assert.java:118)
at org.junit.Assert.assertEquals(Assert.java:144)
at com.impossibl.postgres.jdbc.CodecTest.test(CodecTest.java:320)
at com.impossibl.postgres.jdbc.CodecTest.testTextCodecs(CodecTest.java:157)
gsmet@gsmet:~$ date
Wed Feb 26 19:02:20 CET 2014
I have a couple of tests failing for this reason.
Other than that, they all pass (and there are a lot of them...)
--
Guillaume