Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]

[Lance J. Andersen]

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.