db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: metadata / getClientInfo()
Date Mon, 25 Jul 2011 19:35:53 GMT
Thomas Hill <Thomas.K.Hill@t-online.de> writes:

> okay - true. 
> I was however wondering and wanted to test whether I could replace a
> potentially in terms of performace more costly JDBC statement definition
> and result set processing of a 'select session_user from sysibm.sysdummy1'

or you could prepare a statement as 'VALUES SESSION_USER'.

>  by an assumed less costly request of a property from a connection
> object 
> I have  at hand anway?
> Even if this would turn out to not be better in terms of performance, I 
> think I would still like to understand how this getClientInfo() works. 
> When using SQuirreL I can see a lot of connection properties / metadata
> displayed under their 'metadata' tab that I would suspect they are getting
> via such mechanisms.
> In the derby docs I am afraid one hardly finds details on the subject.

Derby doesn't support getClientInfo, it appears; I found this in the
code (abbreviated by me):

     * <code>getClientInfo</code> always returns an empty
     * <code>Properties</code> object since Derby doesn't support
     * ClientInfoProperties....
    public Properties getClientInfo() throws SQLException{
        return new Properties();

I found only one reference in the reference manual, here:


"Capability reports - JDBC 4.0 adds new methods for querying the
capabilities of a database. These include
autoCommitFailureClosesAllResultSets, providesQueryObjectGenerator,
getClientInfoProperties, and supportsStoredFunctionsUsingCallSyntax. "

I believe "getClientInfoProperties" is a typo for getClientInfo.


View raw message