Обсуждение: 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