Re: [jira] Commented: (DERBY-142) ResultSetMetaData.isReadOnly() also returns wrong results

[Satheesh Bandaram]

Great... Thanks for discussing this at the EG this week. Please let us know of any outcome, if possible. I am willing to address the problem either way, once we reach some conclusion. Here are some of the points to consider: ODBC spec is unambiguous... It says ResultSetMetaData.isReadOnly() should return information about the result column, not the base column. JDBC doesn't need to follow ODBC here, but something to keep in mind. Thomas Fischer seems to indicate many JDBC drivers implement isReadOnly to refer to base column, not the result column. But my testing with DB2 seems to indicate that isReadOnly() returns information about the result column NOT the base column. I haven't tested with other database drivers. Both you and Dan pointed to the fact that this method was there in JDBC 1.0, which predates updatable resultsets. It would make more sense to make ResultSetMetaData.isReadOnly() to reflect ResultSet itself, rather than the base table. DatabaseMetaData might be more appropriate for checking for read/writeOnly info for base columns. Again, I am OK with implementing a consensus either way. Hope we can reach one, quickly. :-) Satheesh Lance J. Andersen wrote: As i mentioned earlier, i will be addressing the lack of clarity in the JDBC 4.0 spec, for the public draft (EDR2 just went to the JCP and should be posted shortly)/ These metadata methods were added during the initial JDBC 1.0.2 release which was prior to updatable resultsets within jdbc.    I am going to be discussing this in my weekly EG call this week. -lance Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-142?page=comments#action_12331849 ] Jean T. Anderson commented on DERBY-142: ---------------------------------------- So Torque uses Village ( http://www.softwareforge.de/releases/village/ ) to insert/modify datasets. Here are a few more details about what Village does under the hood after a (very quick) look at it. (Torque lurkers should feel free to correct these details.) Village obtains the schema for a given table with this query: String sql = "SELECT " + columnsAttribute + " FROM " + tableName + " WHERE 1 = -1"; This query will work in any database, so this much makes sense. And it also makes sense to me that they wouldn't include a "FOR UPDATE" clause on it. At this point, they're just building internal information about the schema. Information for each column is then obtained with the ResultSetMetaData methods, including whether or not the column is writeable with that isReadOnly method call. The Village method that inserts a new row only does so if the columns are writeable. Hence the current problem. I'm looking at the jdbc docs at http://java.sun.com/j2se/1.4.2/docs/api/java/sql/ResultSetMetaData.html and I'm not seeing clearly whether these metadata calls are intended to just describe columns in the result set or columns in the underlying table: - isReadOnly: "Indicates whether the designated column is definitely not writable." - isWritable: "Indicates whether it is possible for a write on the designated column to succeed.". What is the "designated column"? Just the result set? Or could it also refer to the underlying table? I'm looking at the "JDBC API Tutorial and Reference, Third Edition", and section 27.1.19 on "Queries That Produce Updateable Result Sets" suggests to me a strong association with the permissions on the underlying table. --I'm left wondering what it might mean to update a result set outside the context of an underlying table. ResultSetMetaData.isReadOnly() also returns wrong results --------------------------------------------------------- Key: DERBY-142 URL: http://issues.apache.org/jira/browse/DERBY-142 Project: Derby Type: Sub-task Components: JDBC Versions: 10.0.2.1 Environment: Using DB2 universal driver with standalone derby server Reporter: Thomas Fischer Attachments: DerbyTest.java, DerbyTest142.java ResultSetMetaData.isReadOnly() always returns true, even when writing to the table is possible. The JDBC 2.0 spec says: "ResultSetMetaData.isReadOnly() : Indicates whether the designated column is definitely not writable.", so the method should return false for a table. I will attach a testcase for this behaviour.