[
http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425042 ]
Dag H. Wanvik commented on DERBY-1252:
--------------------------------------
Two patches are uploaded to solve this issue.
derby1252-10.1.{diff,stat}
derby1252.{diff,stat}
The first patch to the 10.1 trunk contains extensions to
jdbcapi/metadata_test.java (plus updated masters, hope I got them
all..) which can be used to verify the regression; the old version did
not contain the calls to the methods of interest, see below. I am not
sure it is necessary to commit this patch, but it is useful when
verifying the main patch.
The main patch to 10.2. trunk implements "alternative 2" outlined
earlier in this issue. BTW, alternative 1 is not workable since all
logic on the server side is generic query processing making it ugly to
differentiate between clients.
Patch details:
- metadata_net.properties has been rolled back to the 10.1 version of
the four values which gave regression:
deletesAreDetected(TYPE_SCROLL_INSENSITIVE)
updatedAreDetected(TYPE_SCROLL_INSENSITIVE)
ownDeletesAreVisible(TYPE_SCROLL_INSENSITIVE)
ownUpdatesAreVisible(TYPE_SCROLL_INSENSITIVE)
Derbynet master has been updated to reflect this (existing master
reflects the regression).
- am/DatabaseMetaData.java contains logic to override these to "true"
when running against a >= 10.2. server. I also added code, which is
presently commented out, to negotiate down (effectivly an "AND" for
these boolean values) once the server can start returning the
correct values. As far as I can understand, this cannot happen until
we hit the next major release, 11, due to the forward compatibility
requirements for client/server,
cf. http://wiki.apache.org/db-derby/ForwardCompatibility.
- If the present solution is committed I will file a JIRA to be fixed
for Derby 11 (not possible yet?) , to move to the new regime from
Derby 11.0.
Testing:
- Ran derbyall on 10.1 trunk with the extended 10.1 metadata test
(derby1252-10.1.diff):
derbyall/derbynetmats/derbynetmats.fail:derbynet/DerbyNetAutoStart.java
derbyall/derbyall.fail:unit/T_Diagnosticable.unit
This is unrelated.
- Ran derbyall on 10.2 trunk with the patch (derby1252.diff):
wisconsin fails for all clients, plus store/TransactionTable.sql
(same as tinderbox).
- Ran 10.1 client and extended 10.1 metadata test against current 10.2
to show regression: Ok, shows regression.
- Ran JCC client and extended 10.1 metadata test against current 10.2
to show regression: Ok, shows regression.
- Ran 10.1 client and extended 10.1 metadata test against patched 10.2
to show regression has gone away: OK.
- Ran JCC client and extended 10.1 metadata test against patched 10.2
to show regression has gone away: OK.
- Ran patched 10.2 client against 10.1 server and and extended 10.1
metadata test to see that the patched 10.2 client downgrades
correctly: OK
The patch is ready for review.
> 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
> Assigned To: Dag H. Wanvik
> Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby1252-10.1.diff, derby1252-10.1.stat,
> derby1252.diff, derby1252.stat
>
>
> 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
