You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Satheesh Bandaram <sa...@Sourcery.Org> on 2005/10/08 11:31:13 UTC
[Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
I cleaned up the instructions a little and put them here:
http://db.apache.org/derby/integrate/db_torque.html
Also, note that Torque currently only works with the derby embedded
driver, not with the derby network client. For details see
http://issues.apache.org/jira/browse/DERBY-142 .
-jean
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by "Lance J. Andersen" <La...@Sun.COM>.
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.
>
>
>
>
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
Francois Orsini wrote:
> I agree with Sateesh that the Embedded driver should return TRUE if the
> current statement has no FOR UPDATE in it - This is how I would see it
> and the ODBC description confirms it (as we know many of these semantics
> are coming from ODBC - as Lance pointed out).
One side effect, however, will be that Derby won't work where others do.
This from
http://mail-archives.apache.org/mod_mbox/db-torque-dev/200510.mbox/%3cOFBD6806DB.C10D10BC-ONC1257096.005840D3-C1257096.0059161D@seitenbau.net%3e
:
> All I can say to this discussion is that from my experience with Torque,
> the other database drivers I have worked with (Mysq, Postgresql, Oracle,
> Firebird, HSQLDB) return that the column is _NOT_ readonly if it is an
> ordinary table, so if the Network driver behaviour would be retained, derby
> would be the only database with that behaviour.
So if we fix the embedded jdbc driver we just need to be prepared for
breakage and a difference in behavior from the other drivers.
Torque is calling a village module that has this problem. I'll try to
find time to dig into village and see exactly what it's doing.
-jean
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by Francois Orsini <fr...@gmail.com>.
I agree with Sateesh that the Embedded driver should return TRUE if the
current statement has no FOR UPDATE in it - This is how I would see it and
the ODBC description confirms it (as we know many of these semantics are
coming from ODBC - as Lance pointed out).
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by Francois Orsini <fr...@gmail.com>.
Well in the case of ResultSetMetaData.isSearchable, ODBC semantics are
pretty clear.
Looking at the ODBC SQL_DESC_SEARCHABLE attribute and confirmed by Lance:
SQL_PRED_SEARCHABLE states, "if the column can be used in a WHERE clause
with any comparison operator." It definitely applies to the WHERE clause and
was added specifically so interactive applications could choose which
comparison operators (if any) could be used in a drop down box for query
builder type sequences.
So yes ResultSetMetaData.isSearchable applies to the Table ;)
--francois
On 10/11/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
>
> The ODBC argument is pretty powerful that the ResultSetMetaData
> describes the ResultSet, not the underlying table.
> But then we have ResultSetMetaData.isSearchable, that definitely is
> describing the underlying table and not the result set. Maybe it's the
> exception that proves the rule :-)
>
> Dan.
>
>
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Satheesh Bandaram wrote:
> I interpret ResultSetMetaData to describe the ResultSet, not the base
> column of the table. If someone is interested in knowing whether a
> column of a table is readonly/definetely not writable, wouldn't they be
> using DatabaseMetaData or some other API to check that? I would expect
> ResultSetMetaData to describe the ResultSet itself, like
> Connection.isReadOnly() would indicate if a connection is readonly not
> if the database itself is readonly.
>
> I agree this could be cleared in the spec. I looked at ODBC spec at
> Microsoft site. While there is no 1-1 matching between JDBC and ODBC,
> the following does this seem to favor my argument. Should we have a show
> of hands if this ODBC spec agrees with my argument or not? :-)
The ODBC argument is pretty powerful that the ResultSetMetaData
describes the ResultSet, not the underlying table.
But then we have ResultSetMetaData.isSearchable, that definitely is
describing the underlying table and not the result set. Maybe it's the
exception that proves the rule :-)
Dan.
>
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/htm/odbcresult_set_metadata.asp
>
> SQL_DESC_UPDATABLE
> (ODBC 1.0) Column is described by the values for the defined constants:
>
> SQL_ATTR_READONLY
> SQL_ATTR_WRITE
> SQL_ATTR_READWRITE_UNKNOWN
>
> SQL_DESC_UPDATABLE *describes the updatability of the column in the
> result set, not the column in the base table*. The updatability of the
> base column on which the result set column is based may be different
> from the value in this field. Whether a column is updatable can be based
> on the data type, user privileges, and the definition of the result set
> itself. If it is unclear whether a column is updatable,
> SQL_ATTR_READWRITE_UNKNOWN should be returned.
Re: [Fwd: Re: How to run the Apache DB Torque tutorial with Derby]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
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.