[jira] Commented: (DERBY-970) Add new metadata methods to network client driver

["Knut Anders Hatlen (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-970?page=comments#action_12369251 ] 

Knut Anders Hatlen commented on DERBY-970:
------------------------------------------

Most of the JDBC 4 DatabaseMetaData methods that return a ResultSet
are implemented in the embedded driver. I can think of many ways to
implement them in the client driver, but I don't like any of them very
much.

The current pattern for implementing such methods is:

  1) write a query and put it in metadata.properties

  2) implement method in EmbedDatabaseMetaData executing query in
     metadata.properties

  3) create system procedure in SystemProcedures, calling the method
     through the java.sql.DatabaseMetaData interface

  4) implement method in the client driver, calling the system
     procedure

Since JDK 1.6 compilation is optional, step 3 is not possible without
using reflection. There are (at least) two ways that step can be
performed with reflection:

  a) find and invoke the correct JDBC 4 DatabaseMetaData method with
     reflection

  b) have some kind of JDBC 4 SystemProcedure factory which can load a
     class compiled under JDK 1.6

Then there is the possibility to break the current pattern and let the
client execute the query directly instead of going through the system
procedure. Two options:

  c) hard code the query in the client driver (already used for some
     metadata methods returning an empty ResultSet, in which case it
     is OK?)

  d) let client access metadata.properties (by letting ant copy the
     file)

My objections to these approaches are:

Approach a will result in messy and hard to read code where all sorts
of exceptions need to be caught and handled.

Approach b needs at least two additional java files (interface and
implementation) which seems like too much complexity for something
this simple.

Approach c duplicates code (that is, SQL code).

Approach d can cause compatibility problems if the name of a system
table/schema changes in a subsequent Derby version.

Also, approaches c and d won't create and store an SPS (stored
prepared statement). Is performance a big issue for metadata calls?

I would appreciate getting some advice on which of these ugly
solutions to choose. Of course, if someone has a solution that is not
ugly, I would appreciate that too!

Thanks!

> Add new metadata methods to network client driver
> -------------------------------------------------
>
>          Key: DERBY-970
>          URL: http://issues.apache.org/jira/browse/DERBY-970
>      Project: Derby
>         Type: Sub-task
>     Reporter: David Van Couvering
>     Assignee: Knut Anders Hatlen

>
> Implement new JDBC 4.0 DatabaseMetaData methods in the client driver:
>   - supportsStoredFunctionsUsingCallSyntax()
>   - autoCommitFailureClosesAllResultSets()
>   - getClientInfoProperties()
>   - providesQueryObjectGenerator()
>   - getSchemas()

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira