Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Sun, 09 Oct 2005 10:18:22 -0400
From: "Lance J. Andersen" <Lance.Andersen@Sun.COM>
Subject: Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
In-reply-to: <4347DD02.3090102@debrunners.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <434926AE.6080702@sun.com>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary="Boundary_(ID_E5opJ3jnNUbNPCYS4wNHGQ)"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2)
 Gecko/20040804 Netscape/7.2 (ax)
References: <434791E1.5000605@Sourcery.Org> <4347DD02.3090102@debrunners.com>

This is a multi-part message in MIME format.

--Boundary_(ID_E5opJ3jnNUbNPCYS4wNHGQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

i wil look to try and clear this up.  This comes like most of the other 
metadata from ODBC and it is probably tied to what acces the user was 
granted to the specific column .  EDR2 which i am pushing this week to 
the JCP has many clarifications in the javadocs and spec.  Still a long 
way to go, but the spec is starting to be much clearer.


-lance

Daniel John Debrunner wrote:

>Satheesh Bandaram wrote:
>  
>
>>I took a quick look at this bug. It seems to me Derby Client is behaving
>>as expected rather than the embedded driver though it doesn't seem like
>>it. The query in question gets a ResultSet and its metadata as:
>>
>>           ResultSet rs = s.executeQuery("SELECT id, name FROM
>>readonlytest");
>>           ResultSetMetaData metaData = rs.getMetaData();
>>           if (metaData.isReadOnly(1))
>>                System.out.println("ID column is readonly");
>>
>>Since a FOR UPDATE clause is not specified, the resultset that is
>>returned is *readonly*, which is what Derby client returns for
>>metaData.isReadOnly(1). Once a FOR UPDATE clause is added, Derby client
>>doesn't report the column as readonly.
>>
>>The problem is really with the embedded driver... Even when FOR UPDATE
>>clause is not specified, current implementation of isReadOnly() still
>>returns FALSE, when returning TRUE seems more correct.
>>    
>>
>
>I would say no, the definition of isReadOnly (from the javadoc) is:
>
>"Indicates whether the designated column is definitely not writable."
>
>Since embedded doesn't know, false is the correct answer, true would
>imply embedded knew *definitely* it wasn't writeable.
>
>Though of course, the spec could be cleared up, writable in what sense?
>Through a positioned update/dml, through updateable result set, through
>any DML statement? I think this method has been there since JDBC 1.1 so
>that means it cannot mean just with respect to updateable result sets
>since they were added in JDBC 2.0. Which probably means is the column
>definitely not writable by any operation.
>
>Dan.
>
>
>  
>

--Boundary_(ID_E5opJ3jnNUbNPCYS4wNHGQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
i wil look to try and clear this up.&nbsp; This comes like most of the other
metadata from ODBC and it is probably tied to what acces the user was
granted to the specific column .&nbsp; EDR2 which i am pushing this week to
the JCP has many clarifications in the javadocs and spec.&nbsp; Still a long
way to go, but the spec is starting to be much clearer.<br>
<br>
<br>
-lance<br>
<br>
Daniel John Debrunner wrote:
<blockquote cite="mid4347DD02.3090102@debrunners.com" type="cite">
  <pre wrap="">Satheesh Bandaram wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">I took a quick look at this bug. It seems to me Derby Client is behaving
as expected rather than the embedded driver though it doesn't seem like
it. The query in question gets a ResultSet and its metadata as:

           ResultSet rs = s.executeQuery("SELECT id, name FROM
readonlytest");
           ResultSetMetaData metaData = rs.getMetaData();
           if (metaData.isReadOnly(1))
                System.out.println("ID column is readonly");

Since a FOR UPDATE clause is not specified, the resultset that is
returned is *readonly*, which is what Derby client returns for
metaData.isReadOnly(1). Once a FOR UPDATE clause is added, Derby client
doesn't report the column as readonly.

The problem is really with the embedded driver... Even when FOR UPDATE
clause is not specified, current implementation of isReadOnly() still
returns FALSE, when returning TRUE seems more correct.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I would say no, the definition of isReadOnly (from the javadoc) is:

"Indicates whether the designated column is definitely not writable."

Since embedded doesn't know, false is the correct answer, true would
imply embedded knew *definitely* it wasn't writeable.

Though of course, the spec could be cleared up, writable in what sense?
Through a positioned update/dml, through updateable result set, through
any DML statement? I think this method has been there since JDBC 1.1 so
that means it cannot mean just with respect to updateable result sets
since they were added in JDBC 2.0. Which probably means is the column
definitely not writable by any operation.

Dan.


  </pre>
</blockquote>
</body>
</html>

--Boundary_(ID_E5opJ3jnNUbNPCYS4wNHGQ)--