Обсуждение: Interpretability with xDBC specification
Hi All,
In this mail chain I propose to make a seamless migration path
towards PostgreSQL. There are people who like to migrate from other database
to PostgreSQL. However first problem in that comes is related to feature
compliance and code-changes for same.
Remember that code-change remains as a big hindrance for any
programmer/company.
To start with I'd like to propose compliance for JDBC and ODBC
drivers. Reason for JDBC/ODBC selection is with the facts that
1> Specifications for both are into proper place,
2> Mostly application programmers communicate with this method
There are some specification; example setQueryTimeout of JDBC; which
PostgreSQL doesnot complies.
Non compliance could be fine at some extent. But here problem is
when a code which is written for database supporting setQueryTimeout and
when we planned to test PostgreSQL we got exception from driver.
To move further require to comment out all that code and then
progress further.
Now I propose to not throwing any exception there. It is better if
PostgreSQL - JDBC/ODBC doesnot honor this method. It is painful to change
product source-code for this limitation.
I donot have idea on debug facility in PostgreSQL - JDBC/ODBC. If
you have some debug-log framework available then such non-implemented call
could be part of high level debugging messages.
Please share your opinion/comments.
Hi Sumit, You would do well to read the list archives specifically for this topic. There have been many posts of late. Dave On Mon, Jul 5, 2010 at 6:59 AM, Sumit Pandya <sumit.pandya@elitecore.com> wrote: > Hi All, > In this mail chain I propose to make a seamless migration path > towards PostgreSQL. There are people who like to migrate from other database > to PostgreSQL. However first problem in that comes is related to feature > compliance and code-changes for same. > Remember that code-change remains as a big hindrance for any > programmer/company. > > To start with I'd like to propose compliance for JDBC and ODBC > drivers. Reason for JDBC/ODBC selection is with the facts that > 1> Specifications for both are into proper place, > 2> Mostly application programmers communicate with this method > > There are some specification; example setQueryTimeout of JDBC; which > PostgreSQL doesnot complies. > > Non compliance could be fine at some extent. But here problem is > when a code which is written for database supporting setQueryTimeout and > when we planned to test PostgreSQL we got exception from driver. > > To move further require to comment out all that code and then > progress further. > > Now I propose to not throwing any exception there. It is better if > PostgreSQL - JDBC/ODBC doesnot honor this method. It is painful to change > product source-code for this limitation. > > I donot have idea on debug facility in PostgreSQL - JDBC/ODBC. If > you have some debug-log framework available then such non-implemented call > could be part of high level debugging messages. > > Please share your opinion/comments. > > > -- > Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-jdbc >
Dave,
I could not find any message on topic of such generic level of JDBC
compliance which can lead to higher interpretability. Understand my
perspective of mail is neither of PostgreSQL USER and nor of setQueryTimeout
issue.
I made a generic suggestion which give higher adaptability to people
who are willing to migrate to PostgreSQL. That will be first step towards
increasing PostgreSQL community. I believe that clarify my intent properly.
P.S.> Please point me to mail-thread w.r.t. this intention/subject
-----Original Message-----
From: davecramer@gmail.com [mailto:davecramer@gmail.com] On Behalf Of Dave
Cramer
Sent: Tuesday, July 06, 2010 4:15 PM
To: Sumit Pandya
Cc: pgsql-jdbc@postgresql.org
Subject: Re: [JDBC] Interpretability with xDBC specification
Hi Sumit,
You would do well to read the list archives specifically for this
topic. There have been many posts of late.
Dave
On Mon, Jul 5, 2010 at 6:59 AM, Sumit Pandya <sumit.pandya@elitecore.com>
wrote:
> Hi All,
> In this mail chain I propose to make a seamless migration path
> towards PostgreSQL. There are people who like to migrate from other
database
> to PostgreSQL. However first problem in that comes is related to feature
> compliance and code-changes for same.
> Remember that code-change remains as a big hindrance for any
> programmer/company.
>
> To start with I'd like to propose compliance for JDBC and ODBC
> drivers. Reason for JDBC/ODBC selection is with the facts that
> 1> Specifications for both are into proper place,
> 2> Mostly application programmers communicate with this method
>
> There are some specification; example setQueryTimeout of JDBC;
which
> PostgreSQL doesnot complies.
>
> Non compliance could be fine at some extent. But here problem is
> when a code which is written for database supporting setQueryTimeout and
> when we planned to test PostgreSQL we got exception from driver.
>
> To move further require to comment out all that code and then
> progress further.
>
> Now I propose to not throwing any exception there. It is better if
> PostgreSQL - JDBC/ODBC doesnot honor this method. It is painful to change
> product source-code for this limitation.
>
> I donot have idea on debug facility in PostgreSQL - JDBC/ODBC. If
> you have some debug-log framework available then such non-implemented call
> could be part of high level debugging messages.
>
> Please share your opinion/comments.
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc
>
Sumit Pandya wrote: > Dave, > I could not find any message on topic of such generic level of JDBC > compliance which can lead to higher interpretability. Understand my > perspective of mail is neither of PostgreSQL USER and nor of setQueryTimeout > issue. > I made a generic suggestion which give higher adaptability to people > who are willing to migrate to PostgreSQL. That will be first step towards > increasing PostgreSQL community. I believe that clarify my intent properly. As far as I know, the JDBC driver is mostly compliant with the specification already. What are the cases (other that setQueryTimeout() that you already mentioned) that you have problems with? We can't fix incompatibilities if you don't tell us what they are .. -O
On Tue, Jul 6, 2010 at 7:30 AM, Sumit Pandya <sumit.pandya@elitecore.com> wrote: > Dave, > I could not find any message on topic of such generic level of JDBC > compliance which can lead to higher interpretability. Understand my > perspective of mail is neither of PostgreSQL USER and nor of setQueryTimeout > issue. > I made a generic suggestion which give higher adaptability to people > who are willing to migrate to PostgreSQL. That will be first step towards > increasing PostgreSQL community. I believe that clarify my intent properly. > Sumit, My reference was to exactly the setQueryTimeout discussion, not a general discussion. As Oliver pointed out, please tell us what is not compliant so that we can address this. It is my experience that "compliant" means the way that "XYZ" does it. The spec is very vague in many areas so there is lots of room for interpretation. This makes it difficult to be compliant. Dave
Dear Oliver and Dave,
setQueryTimeout was just my startup hindrance and "dummy xDBC
compliance" was a virgin thought-process.
I'm not confident but 100% sure that there would be many other xDBC API
which are either partial or unimplemented.
It could be better if we prepare a table for "ALL" JDBS/ODBC API and
flag for Partial/Roadmap/Not compliance. Here I'm purposely not opting the
API where "Full" compliance is there. It is useful in a sense of doing
meaningful/required work with the subject.
Please excuse me if there is already such FAQ/White-Paper and in that
case share link. We could have that information filled with xDBC
specification version wise as below.
---------------------------------------------------------------------
JDBC-ver API PostgreSQL-ver compliance Plan-Date
---------------------------------------------------------------------
2.0 setQueryTimeout 8.2 P November
2010
9.0 R
September 2010
---------------------------------------------------------------------
3.0 XAConnections 8.x N.A.
9.0 R
October 2010
---------------------------------------------------------------------
3.0 BaseRowSet.setBlob(arg)
8.0 N.A.
9.0 F
---------------------------------------------------------------------
In above reason for N.A. could be 8.x version doesnot have distributed
processing support and Blob type support respectively.
Trust me that I'm not here ONLY because I'm planning porting to
PostgreSQL. My intention is wide acceptability and clear migration towards
PostgreSQL.
Either of below links should be nice reference for compliance sheet
http://java.sun.com/javase/7/docs/api/java/sql/package-summary.html
http://java.sun.com/javase/7/docs/api/javax/sql/package-summary.html
http://jcp.org/aboutJava/communityprocess/final/jsr221/index.html
-----Original Message-----
From: Oliver Jowett [mailto:oliver@opencloud.com]
Sent: Tuesday, July 06, 2010 5:11 PM
As far as I know, the JDBC driver is mostly compliant with the
specification already. What are the cases (other that setQueryTimeout()
that you already mentioned) that you have problems with? We can't fix
incompatibilities if you don't tell us what they are ..
-O
Sumit Pandya wrote: > Please excuse me if there is already such FAQ/White-Paper and in that > case share link. http://jdbc.postgresql.org/todo.html might be a start. If you'd like to prepare a compliance table yourself, I'm sure the list would be interested in the results. I should forewarn you, though, that the last time I checked, obtaining and setting up the JDBC CTS or TCK was a lot of work. -O
On Tue, Jul 6, 2010 at 10:15 AM, Oliver Jowett <oliver@opencloud.com> wrote: > Sumit Pandya wrote: > >> Please excuse me if there is already such FAQ/White-Paper and in that >> case share link. > > http://jdbc.postgresql.org/todo.html might be a start. > > If you'd like to prepare a compliance table yourself, I'm sure the list > would be interested in the results. I should forewarn you, though, that > the last time I checked, obtaining and setting up the JDBC CTS or TCK > was a lot of work. We actually got it to pass at one point when SUN was interested, and they did most of the work. Unfortunately you have to bend postgresql in ways it was never intended to work to get it to pass. Dave
Oliver Jowett <oliver@opencloud.com> wrote:
> If you'd like to prepare a compliance table yourself, I'm sure the
> list would be interested in the results.
FWIW, we took a great deal of care to keep our code portable and had
few problems converting to PostgreSQL. Probably the biggest problem
for *us* was the fact that {fn IFNULL(NULL, NULL)} didn't return the
same thing as a bare NULL literal. A bare NULL is of unknown type,
whereas this escape sequence returns a NULL coerced to the TEXT
type, which didn't work very well in some contexts when the
arguments were dates or numbers.
I understand why this is hard to handle in the PostgreSQL backend
for COALESCE, but we were able to get past it in JDBC by hacking the
driver to replace "{fn IFNULL(NULL, NULL)}" with "NULL" -- as a
stopgap until we could push type information far enough down into
statement generation to wrap the NULL arguments, so that we were
generating "{fn IFNULL(CAST(NULL AS INTEGER), CAST(NULL AS
INTEGER))}" instead. While I agree that pushing that type
information down and generating the CASTs into the statement is
better, I don't believe that current behavior here is strictly
compliant for the {fn IFNULL()} portability escape. In any event,
something similar to the hack I used (although it would have to be
made more bullet-proof) might ease migration to PostgreSQL for some.
-Kevin
Dave Cramer wrote: > My reference was to exactly the setQueryTimeout discussion, not a > general discussion. As Oliver pointed out, please tell us what is not > compliant so that we can address this. > > It is my experience that "compliant" means the way that "XYZ" does it. > The spec is very vague in many areas so there is lots of room for > interpretation. This makes it difficult to be compliant. Case in point: The Javadocs for 'setQueryTimeout()' only promise that it will throw 'SQLException' for an argument < 0 or for a query that exceeds its timeout, not that it will not throw 'SQLException' for an argument >= 0. Therefore one could argue that the method as implemented does comply. -- Lew