db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1252) Old clients with new server return wrong database metadata values for some methods
Date Tue, 25 Jul 2006 14:31:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423343 ] 
            
Dag H. Wanvik commented on DERBY-1252:
--------------------------------------

Impact:

This regression affects client which do not support updatable,
scrollable, insensitive result sets; i.e. JCC and Derby client driver
<= 10.1.x.

Since the metadata methods which experience the regression all concern
either detectability or visibility of updatable, scrollable,
insensitive result sets, which is a new feature in 10.2, it seems a
long stretch to imagine existing applications being negatively
impacted: Why would an application ask about details of a feature not
supported? [DataBaseMetaData#supportsResultSetConcurrency and
supportsResultSetType should be used to determine if SUR is supported,
and these work correctly for the mixed scenarios (derby 10.1/derby
10.2 server and jcc client/derby 10.2 server┬╣).

┬╣Albeit due to luck; a bug in the parsing of a returned metadata
 column in both JCC and Derby client <= 10.1, see also this thread:
 http://www.mail-archive.com/derby-dev@db.apache.org/msg18334.html)

In general, though, the bug reveals an exisiting weakness in the
design of the mechanism to answer database metadata methods on the
client; the server does not take the client version into account when
answering (negotiate down). Mostly, this should only be a problem when
the server is newer (has more features) than the client can support.

Possible Solutions:

One solution could be: If in a mixed scenario, make the stored
procedure SYSIBM.METADATA() being executed on the server on behalf of
the client, return data from a 10.1-compatible version of the
metadata.

The query METADATA in the file metadata_net.properties is used to construct
the stored prepared statement used by SYSIBM.METADATA(). We could have
a "client <= 10.1" version of the query which can be referenced by
SYSIBM.METADATA(). This presupposes that the JCC driver also accesses
the metadata via the stored procedure SYSIBM.METADATA().

Downside: Redundancy in data, possible proliferation of more version
specific versions later? I presume we need to keep them
around til we hit Derby 11.

An alternative (more ad hoc and ugly) would be to always let the
server return false for these metadata calls, and let the derby client
ignore the values returned and hardcode the values for these methods
into the derby driver based on which version of the server it is
talking to: server < 10.2 false, server >= 10.2 : true.

Not sure I like either of the approaches.. But is the regression too
risky to accept?






> Old clients with new server return wrong database metadata values for some methods
> ----------------------------------------------------------------------------------
>
>                 Key: DERBY-1252
>                 URL: http://issues.apache.org/jira/browse/DERBY-1252
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC, Network Client, Network Server
>    Affects Versions: 10.1.1.0, 10.1.2.0, 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2,
10.1.2.3, 10.1.2.4
>            Reporter: Dag H. Wanvik
>            Priority: Minor
>             Fix For: 10.2.0.0
>
>
> With an old client (10.1.1, 10.1.2) accessing a new (10.2) server,
> some metadata calls will return the wrong value for both the JCC and
> the Derby clients:
> 	 deletesAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
> 	 updatedAreDetected(TYPE_SCROLL_INSENSITIVE) -> true
> 	 ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> 	 ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE) -> true
> This happens because these values were changed for the 10.2 with
> the addition of updatable scrollable insensitive result sets (DERBY-775),
> combined with a weakness in the way the client and the server 
> cooperates to answer these metadata calls.
> Presently, when the client application invokes these methods, the
> results will be returned by the server without regard to the identity
> of the client, i.e. the 2-tuple {JCC or Derby client, client version}.
> The values to be returned for the methods in question are based solely
> on the values found in the file metadata_net.properties, which is part
> of the server.
> In general, some database metadata is dependent on the combination of
> the capabilities in the client and the server and the returned values
> should reflect this, which in general implies negotiating (down) to
> values which are correct for the actual combination of client and
> server.

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