db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Disussion surrounding holding off metadata changes until certain issues resolved
Date Sun, 09 Apr 2006 05:17:04 GMT
Kathey Marsden <kmarsdenderby@sbcglobal.net> writes:

>>As I was working with DERBY-775, it struck me that the JCC client
>>might get problems when metadata_net.properties is updated to reflect
>>Derby client capabilities not necessarily present in the JCC driver.
>>Should there perhaps be different code paths for the two drivers(JCC,
>>DerbyNetClient) wrt SYSIBM metadata? Not my itch, but...
>
> I am not clear on the specific issue you are referring to, but  such

The metadata methods in question are supportsResultSetConcurrency,
ownDeletesAreVisible, ownUpdatesAreVisible, deletesAreDetected and
updatesAreDetected. With client SUR (not yet committed), they now
return true for scrollable insensitive result set types.

> compatibility issues would I think also exist when running with the
> original client release, Derby 10.1 and the new server. No ?   

Yes and no, cf the explanation from the DERBY-775 writeup:

> Old client, new server scenario: In this case, the downgrade of the
> result set happens on the client, so applications would not be able
> to use SUR. Only the new client lifts the restriction.
> 
> Due to the bug in the 10.1 client code for
> supportsResultSetConcurrency (DERBY-965), the client would still get
> a "false" on this query, which is correct. Note that this is be
> accident rather than by design! Derby has a weakness here in that
> metadata queries are answered by the server without regard to the
> client's version (capabilities).
> 
> For the detectability metadata calls, the returned values would be
> wrong, but since this is new functionality it should be ok.

The changed value of
supportsResultSetConcurrency(TYPE_SCROLL_INSENSITIVE,
CONCUR_UPDATABLE), now true with the advent of SUR, could in theory
affect JCC client apps, but not 10.1 Derby network driver clients apps
due to the serendipty of DERBY-965: the driver will continue to return
false, as long as the patch for 965 is not back ported to the 10.1
branch. 

Generally, it seems results of such metadata calls should potentially
be "negotiated down" if the client is older and cannot support the new
feature.. I am not sure of the machinery of NetDatabaseMetaData can be
used as is for this purpose...(i.e. the serverSupport<FeatureX>
methods). Or?

Back next week. One week easter vacation, have fun, all!

Dag

Mime
View raw message