You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <de...@db.apache.org> on 2006/04/26 00:01:02 UTC
[jira] Created: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
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
Type: Bug
Components: JDBC, Network Server, Network Client
Versions: 10.0.2.2, 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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425602 ]
Rick Hillegas commented on DERBY-1252:
--------------------------------------
Thanks, Dag. The fix looks solid. Derbyall had two diffs for me: 1) the wisconsin noise, 2) XATest under DerbyNetClient (DERBY-1640). Committed at subversion revision 428510.
> 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.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
[jira] Assigned: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik reassigned DERBY-1252:
------------------------------------
Assignee: Dag H. Wanvik
> 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
>
>
> 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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Attachment: derby1252.stat
derby1252.diff
derby1252-10.1.stat
> 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.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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Attachment: derby1252.diff
whitespace fix for derby1252.diff
> 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.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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Version: (was: 10.0.2.2)
> 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
> Type: Bug
> Components: JDBC, Network Server, Network Client
> 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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Derby Info: [Patch Available, Existing Application Impact, Regression] (was: [Existing Application Impact, Regression])
> 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.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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Rick Hillegas updated DERBY-1252:
---------------------------------
Urgency: Urgent
> 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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Derby Info: [Regression]
Setting regression again, this field should reflect bug property and not be removed when
issue is fixed, cf mail thread http://www.nabble.com/Jira-field-definition-clarification-for-Derby-tf2024859.html#a5567827
> 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.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
Re: [jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by Kathey Marsden <km...@sbcglobal.net>.
Dag H. Wanvik wrote:
I think iregression is good to keep for history. A fixed regresssion
is a fixed regression and that makes sense.
Existing application impact is a tool for users so should reflect the
current state.
>Does anyone know if is it explained elsewhere? If not, I
>think it would be good up update the document.
>
>
>
I sent a proposal for Jira Field clarification for this and other
fields. Please let me know if you have comments.
http://www.nabble.com/Jira-field-definition-clarification-for-Derby-tf2024859.html#a5567827
I will put it up on the Wiki and then hopefully we can phase out the
Word document.
Kathey
Re: [jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik" <Da...@Sun.COM>.
"Kathey Marsden (JIRA)" <de...@db.apache.org> writes:
> [ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425609 ]
>
> Kathey Marsden commented on DERBY-1252:
> ---------------------------------------
>
> now that this is fixed , is there still existing application impact?
> If not then we should uncheck the box. "Existing application
> impact" should a field users can query on to see if there have been
> changes that might affect their application. Once a regression is
> fixed it can be unchecked if there is nothing that remains that
> might impact users.
Yes, I was wondering about that.. For "regression" I guess one could
argue that these flags are a characteristic of the bug, and should be
left, and that, being closed, the problem is gone as
well. "Application impact" seems more belonging to the solution, and
then it gets muddy..
I agree it is more useful (and workable) to let both flags reflect the
current state of the issue (as we do for patch available). I checked
http://db.apache.org/derby/binaries/FilingDerbyIssuesInJira.doc for
explanation of how these fields should be used but didn't find
anything. Does anyone know if is it explained elsewhere? If not, I
think it would be good up update the document.
Thanks,
Dag
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12425609 ]
Kathey Marsden commented on DERBY-1252:
---------------------------------------
now that this is fixed , is there still existing application impact? If not then we should uncheck the box.
"Existing application impact" should a field users can query on to see if there have been changes that might affect their application. Once a regression is fixed it can be unchecked if there is nothing that remains that might impact users.
> 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.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
[jira] Resolved: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik resolved DERBY-1252.
----------------------------------
Resolution: Fixed
Derby Info: [Existing Application Impact, Regression] (was: [Existing Application Impact, Patch Available, Regression])
> 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.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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423879 ]
Dag H. Wanvik commented on DERBY-1252:
--------------------------------------
Yes, that's what I had in mind for my "alternative two" above. If
people are OK with that approach I can make a patch for it.
People finding this solution unacceptable should speak out now. I will
start on it in within a couple of days if there is no push back.
> 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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ 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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423188 ]
Kathey Marsden commented on DERBY-1252:
---------------------------------------
This issue is a regression. It would be ideal to release Derby 10.2 without any known regressions so we don't have to even think about where to draw the line for acceptable regressions, so before I think too much about where to draw that line, I ask:
- How hard this is to fix?
- Does anyone plan to pick this up for 10.2?
> 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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Derby Info: (was: [Regression, Existing Application Impact])
regression gone after fix
> 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.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
[jira] Updated: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik updated DERBY-1252:
---------------------------------
Attachment: derby1252-10.1.diff
> 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
[jira] Closed: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Dag H. Wanvik (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=all ]
Dag H. Wanvik closed DERBY-1252.
--------------------------------
Verified on trunk.
> 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.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
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Rick Hillegas (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423873 ]
Rick Hillegas commented on DERBY-1252:
--------------------------------------
It seems to me that SYSIBM.METADATA exists to support the JCC driver. Maybe we could let this procedure continue to return the 10.1 answers; the 10.2 client could return the 10.2 answers when talking to a 10.2 server.
> 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
Re: Jira Derby Info flags meaning WAS Re: [jira] Commented: (DERBY-1252)
...
Posted by Kathey Marsden <km...@sbcglobal.net>.
Daniel John Debrunner wrote:
>Is there any definition on what these Jira 'Derby Info' flags mean?
>
>Regression
>
>
A Derby product regression that is a bug that hopefully will be fixed.
Example DERBY-1459
>Existing Application Impact
>
>
>
Any change intentional or otherwise that might affect existing
applications, including bug fixes that have a resonable potential to
impact applications negatively.
A user could query before upgrading to find out what issues might affect
their applications, be it regression or intentional.
All regressions have Existing Application Impact but not all issues
with Existing Application Impact are Regressions.
Example DERBY-721
Pehaps a clearer approach would have been for Existing Application
Impact to be "Intentional Behavior Change" so there is not the overlap.
Kathey
Jira Derby Info flags meaning WAS Re: [jira] Commented: (DERBY-1252)
...
Posted by Daniel John Debrunner <dj...@apache.org>.
Is there any definition on what these Jira 'Derby Info' flags mean?
Regression
Existing Application Impact
To me they mean the same thing.
Dan.
Daniel John Debrunner (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423191 ]
>
> Daniel John Debrunner commented on DERBY-1252:
> ----------------------------------------------
>
> How would this regression manifest itself in a working application?
[jira] Commented: (DERBY-1252) Old clients with new server return
wrong database metadata values for some methods
Posted by "Daniel John Debrunner (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1252?page=comments#action_12423191 ]
Daniel John Debrunner commented on DERBY-1252:
----------------------------------------------
How would this regression manifest itself in a working application?
> 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