db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Date Sat, 08 Oct 2005 14:51:46 GMT
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.


View raw message