db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "RPost" <rp0...@pacbell.net>
Subject Re: On DERBY-107 : ODBC Metadata functions
Date Sat, 22 Jan 2005 02:48:22 GMT
I'm still researching but have some questions/comments.

> Option I:
>
> Add new SQL statements, such as "getColumnsForODBC", to the existing
metadata.properties file, as described in the
> proposal for DERBY-107.  Then, since EDM has to know which version of a
given SQL statement to execute--for example,
> should it call the regular "getColumns" version, or should it call the new
"getColumnsForODBC" version?--we could add
> new methods (such as "setForODBC()") to EDM that could be used by
SystemProcedures to indicate (to EDM) that ODBC
> metadata should be returned, intead of JDBC metadata.  Note that, since
SystemProcedures is in a different package than
> EDM, the new methods on EDM would (I think) have to be _public_.
>

For any given instance of EDM will a user potentially be calling both
"getColumns" and "getColumnsForODBC"?  Your comments for option II (add a
protected variable "forODBC) seem to imply that only one or the other will
get called.

If only one set of queries will be executed it there may be a 4th option:
    change the metadata.properties load process to load the version needed.

This could be done in a static block when the driver is first loaded by
adding an option to the URL at connect time.

If the EDM file needs to be modified it may be desireable to move the
current load to a static block anyway rather than wait for the first
request.



Mime
View raw message