Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <1896536723.1140912415179.JavaMail.jira@ajax.apache.org>
Date: Sun, 26 Feb 2006 01:06:55 +0100 (CET)
From: "Kathey Marsden (JIRA)" <derby-dev@db.apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-965) DatabaseMetadata method
 supportsResultSetConcurrency returns wrong result on network client
In-Reply-To: <702071389.1139841807006.JavaMail.jira@ajax.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DERBY-965?page=comments#action_12367798 ] 

Kathey Marsden commented on DERBY-965:
--------------------------------------

I haven't been able to look at this closely to understand the issues, but  I have some questions

Your earlier comment said:
Note that this
raises an upgrade issue, in that the existing client would crash if
the server's data were corrected to the encoding syntax the client
expects (due to the coding bug) but the patch comments made it sound  less severe.

Is there a scenario with this patch where we will get a crash where we did not before?

I  know there was a lot of discussion at one time about changes to metadata.properties and metadata_net.properties for upgrade, soft upgrade and downgrade.  I wonder if someone could point me to the final resolution or explain it if it is brief.  I had always been a fan of drop and recreate on any version change to allow for bug fixing and  prevent intractible upgrade situations.

Also I wanted to mention if you need client to behave differently with different versions you can add something to 
NetDatabaseMetaData.computeFeatureSet

Similarly on the server side AppRequester.java has a mechanism for client version specific behaviour.


> DatabaseMetadata method supportsResultSetConcurrency returns wrong result on network client
> -------------------------------------------------------------------------------------------
>
>          Key: DERBY-965
>          URL: http://issues.apache.org/jira/browse/DERBY-965
>      Project: Derby
>         Type: Bug
>   Components: Network Server, Network Client
>     Versions: 10.2.0.0
>  Environment: Solaris 10, x86, Sun JDK 1.4.2
>     Reporter: Dag H. Wanvik
>     Assignee: Dag H. Wanvik
>     Priority: Minor
>  Attachments: Main.java, derby965-v1.diff, derby965-v1.stat
>
> The DatabaseMetaData method supportsResultSetConcurrency erroneously
> returns false on the network client for all arguments combination, cf
> the attached repro program. The embedded client returns correct
> results, viz the output:
> org.apache.derby.jdbc.ClientDriver:
> SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: false
> SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: false
> SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: false
> SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false
> SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false
> SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false
> org.apache.derby.jdbc.EmbeddedDriver:
> SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_READ_ONLY: true
> SupportsResultSetConcurrency: TYPE_FORWARD_ONLY,CONCUR_UPDATABLE: true
> SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_READ_ONLY: true
> SupportsResultSetConcurrency: TYPE_SCROLL_INSENSITIVE,CONCUR_UPDATABLE: false
> SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_READ_ONLY: false
> SupportsResultSetConcurrency: TYPE_SCROLL_SENSITIVE,CONCUR_UPDATABLE: false
> Presumably, this is wrong in released versions as well.

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