[ 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
