db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: forMetaData
Date Sat, 18 Jun 2005 19:09:36 GMT
Philip Wilder wrote:

> Can anyone give me an explanation on the importance of the forMetaData
> boolean found in the org.apache.derby.jdbc.EmbedStatement class and
> subsequently passed on to any org.apache.derby.jdbc.EmbedResultSet
> class? I'm having difficulty comprehending why DatabaseMetaData
> ResultSets are given more weight then any other ResultSets.
>
Hi Philip,

No firm answers on this but just a couple of research pointers.   

In the jdbcapi/metadata.java test there is a case.

            rs = s.executeQuery("SELECT * FROM SYS.SYSTABLES");

            System.out.println("getColumns('SYSTABLES'):");
            ResultSet rs2 = met.getColumns("", "SYS", "SYSTABLES", null);
            if (!rs.next()) {
                System.out.println("FAIL -- user result set closed by"+
                    " intervening getColumns request");
            }

Which seems to imply that the results from  the metadata call are all 
cached up  and perhaps the special handling keeps that process from
interfering with the user statement. Actually for this case to be
useful, the test should set holdability on the connection to
CLOSE_CURSORS_AT_COMMIT.  With the current Derby
default,HOLD_CURSORS_OVER_COMMIT, this test would pass regardless of
whether the results were cached or not.

You might also check the JDBC spec for information on special handling
of metadata with regard to leaving queries open on the database.  I am
guessing the fact that the Statement object is never returned to the
user complicates things somewhat for metadata..

Hope that helps

Kathey






Mime
View raw message