Thread: DatabaseMetaData
I've taken a look at the results of the dbMeta tests in the JDBC test suite. I know that Peter has taken a look at these so I've just got some additional notes w.r.t. to failures. In dbMeta1, the test for supportsStoredProcedures fails consistently. The method returns false, but the test harness is expecting true and considers false to be an invalid response. The reason for this is that the JDBC test suite is doing tests for J2EE compliance of the JDBC driver being tested, and one of the conditions is that supportsStoredProcedures should always return true. For regular JDBC compliance, returning false is alright. So, ignore those tests (unless we want the JDBC driver to be J2EE compliant). In the PostgreSQL driver, there are some methods that throw SQLExceptions because they are not implemented yet (isCatalogAtStart, getCatalogSeparator, getUDTs). But other unimplemented methods, such as getTablePrivileges, getVersionColumns, getExportedKeys, and getCrossReference return null. Until they are implemented, they should throw an SQLException. null != empty ResultSet, so getTypeInfo should not have a fallback return value of null, but rather should throw an SQLException when the metadata is not available. In general, I think that better checking for unavailable metadata can be done. The SQLExceptions thrown by unimplemented methods will be caught by the JDBC test harness and the tests will be flagged as errors due to the fact, again, that the test suite is testing for J2EE compliance: all methods should be implemented and none should throw exceptions. For more information on the JDBC and J2EE, see the J2EE Api, section 6.2.2.3. Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: liams@redhat.com
On Fri, 10 Aug 2001 11:07:45 -0400, you wrote: >In dbMeta1, the test for supportsStoredProcedures fails consistently. >The method returns false, but the test harness is expecting true and >considers false to be an invalid response. The reason for this is that >the JDBC test suite is doing tests for J2EE compliance of the JDBC >driver being tested, and one of the conditions is that >supportsStoredProcedures should always return true. For regular JDBC >compliance, returning false is alright. I'm not sure if this is true. The JDBC book (http://java.sun.com/docs/books/jdbc/) says in the description of supportsStoredProcedures: "checks whether this database supports stored procedure calls using the stored procedure escape syntax". And in section A.1.3: "... must be supported by a JDBC Compliant driver... Where appropriate, an escape syntax must be included for stored procedures, ...". I see no mention of J2EE with respect to this requirement. >In the PostgreSQL driver, there are some methods that throw >SQLExceptions because they are not implemented yet (isCatalogAtStart, >getCatalogSeparator, getUDTs). But other unimplemented methods, such as >getTablePrivileges, getVersionColumns, getExportedKeys, and >getCrossReference return null. Until they are implemented, they should >throw an SQLException. So noted on http://lab.applinet.nl/postgresql-jdbc/ under "miscellaneous". As an aside, I've just updated this page with an explanation of the Blob/Clob/Lob issues and the proposal from Barry Lind, as well as some other issues that have been posted on this list. >null != empty ResultSet, so getTypeInfo should not have a fallback >return value of null, but rather should throw an SQLException when the >metadata is not available. So noted under "DatabaseMetaData". >In general, I think that better checking for >unavailable metadata can be done. I'm not sure what you mean by that. But maybe I'm the problem, its getting late :-) >The SQLExceptions thrown by unimplemented methods will be caught by the >JDBC test harness and the tests will be flagged as errors due to the >fact, again, that the test suite is testing for J2EE compliance: all >methods should be implemented and none should throw exceptions. They're allowed to throw exceptions by the signature, but they'd better not when the test is running :-) >For more information on the JDBC and J2EE, see the J2EE Api, >section 6.2.2.3. Hmmm... what book are you refering to? I have the "Java 2 EE Platform and Components Specifications", but it doesn't have a section 6.2.2.3. Regards, René Pijlman
On Sat, Aug 11, 2001 at 01:13:34AM +0200, Rene Pijlman wrote: > I'm not sure if this is true. The JDBC book > (http://java.sun.com/docs/books/jdbc/) says in the description > of supportsStoredProcedures: "checks whether this database > supports stored procedure calls using the stored procedure > escape syntax". And in section A.1.3: "... must be supported by > a JDBC Compliant driver... Where appropriate, an escape syntax > must be included for stored procedures, ...". I see no mention > of J2EE with respect to this requirement. Ok, I see what you're looking at. However, the book states the escapes should only be supported when the underlying DBMS supports them and that escape syntaxes must be included for stored procedures etc where appropriate. Does PostgreSQL support stored procedures using a stored procedures escape syntax? If yes, we should return yes, if no, we should return no until that functionality is added. Both cases are allowed, AFAICS. The book doesn't mention that drivers should always return true for this procedure. > >In general, I think that better checking for > >unavailable metadata can be done. > > I'm not sure what you mean by that. But maybe I'm the problem, > its getting late :-) Actually, I'm not sure what I was saying anymore .. :P never mind this statement until I figure it out myself :) > Hmmm... what book are you refering to? I have the "Java 2 EE > Platform and Components Specifications", but it doesn't have a > section 6.2.2.3. "Java 2 EE Specification, v1.2" Liam -- Liam Stewart :: Red Hat Canada, Ltd. :: liams@redhat.com
On Mon, 13 Aug 2001 12:07:59 -0400, you wrote: >Ok, I see what you're looking at. However, the book states the escapes >should only be supported when the underlying DBMS supports them and that >escape syntaxes must be included for stored procedures etc where >appropriate. Does PostgreSQL support stored procedures using a stored >procedures escape syntax? If yes, we should return yes, if no, we should >return no until that functionality is added. Both cases are allowed, >AFAICS. The book doesn't mention that drivers should always return true >for this procedure. You're right. >"Java 2 EE Specification, v1.2" Ah, I see, this is one of the subbooks in my book. Well, I think we'll have to check for J2EE conformance as well, since I guess the driver will be used on J2EE platforms more and more. Regards, René Pijlman