db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-970) Add new metadata methods to network client driver
Date Mon, 13 Mar 2006 18:53:01 GMT
    [ http://issues.apache.org/jira/browse/DERBY-970?page=comments#action_12370219 ] 

Kathey Marsden commented on DERBY-970:
--------------------------------------

Knut Asked:
>By the way, how strict is that rule (That metadata queries be handled on the server side
and not the client)?  

The functional requirement is pretty simple.   On upgrade of the  server or client software,
 the supported public API's, such as JDBC,  that worked in  the old  version  should still
work  after they plop down the new jar file. There should be no additional intervention required
on the part of the user or application developer to get what was working to work once again.
 For example they cannot be required to upgrade the software on the other end of the wire
or make application changes to get things to work.

The implementation of this is complex and can get quite messy.  

For the  metadata queries that means that any query executed by a client needs to work with
server versions  past and future.  Putting an empty ResultSet  query in the client might be
likely always to work just fine because it uses SQL Syntax that has the same requirement.

Many  of the metadata queries, however, use internal interfaces and unsupported syntax and
refer to system table columns that may have been recently added, so maintaining these on the
client would be very difficult.
For example adding the 10.2 metadata.properties to the 10.2 client and having queries executed
that way would break 10.2 client with 10.1 client right away .  To fix with 10.1 we would
have to add the 10.1 metadata.properties to the 10.2 client.  We would also need to preserve
the internal interfaces on the servers of the future so the old clients would continue to
work.

It seems  easier for these to keep the queries tied to the server and then only the stored
procedure names have to stay the same.

Good references regarding the maintenance of all of this on the Wiki from  more architecturally
inclined minds:

http://wiki.apache.org/db-derby/ForwardCompatibility
http://wiki.apache.org/db-derby/SharedComponentVersioningGuidelines#head-021f7965c44f0b0bcb993d3f54922e1b41d53921




> 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
>  Attachments: derby-970-part1-v1.diff, derby-970-part1-v1.stat, derby-970-part2-v1.diff,
derby-970-part2-v1.stat
>
> Implement new JDBC 4.0 DatabaseMetaData methods in the client driver:
>   - supportsStoredFunctionsUsingCallSyntax()
>   - autoCommitFailureClosesAllResultSets()
>   - getClientInfoProperties()
>   - providesQueryObjectGenerator()
>   - getSchemas()
>   - getRowIdLifetime()

-- 
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


Mime
View raw message