This regression affects client which do not support updatable,
scrollable, insensitive result sets; i.e. JCC and Derby client driver
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:
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.
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
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?