Thomas Fischer wrote:
Jean,

Thanks a lot for pushing this Bug to the surface again.

Torque has been on my list for quite a while to work with, but it was a user's post to [email protected] that provided the push.

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.

And possibly DB2 has that behaviour as well because you originally encountered the problem with the DB2 Universal JDBC driver.

It'll be interesting to see how this all works out.

Also, regarding your other remarks about the tutorial, I'll check them in
as soon as I can grasp some time. I'm glad you found the tutorial useful.

I put a page up for derby users here, so you might get some more hits/feedback on the tutorial:

http://db.apache.org/derby/integrate/db_torque.html

cheers,

  -jean


    Thomas


"Jean T. Anderson" <[EMAIL PROTECTED]> schrieb am 10.10.2005 17:50:30:


To quickly summarize, given "SELECT id, name FROM readonlytest", the
Derby embedded driver says that the columns are writeable while the
Derby Network Client (and the DB2 Universal JDBC driver) say the columns
are readonly. Village refuses to insert data for columns that are marked
"readonly".

If you add a "FOR UPDATE" clause to the statement, the Derby Network
Client now says that the columns are writeable, sparking some debate as
to what the correct behavior should be in the both the embedded and
client drivers:

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200510.mbox/%
[EMAIL PROTECTED]

If a "resolution" comes out of this, I'll post it.

 -jean

Jean T. Anderson wrote:

Thomas Fischer wrote:


... By the way, last time I tried it, Torque did not work with Derby
and the
network driver. The problem was that the network driver in the

meta-info

declared all columns to be read-only, which causes a library used
internally in Torque (village) to refuse to write any datasets into

the

table. The problem is described in the Bug DERBY-142 in Derby's Jira.


That explains the many test failures I saw yesterday.  :-) I just
updated DERBY-142 with an additional test based on one of the sample
Derby apps that reproduces the problem with the 10.1 Derby Network

Client.

By the way, there's a typo in

trunks/test/profile/derby/project.properties:

 torque.database.buildUrl = jjdbc:derby:net://localhost/test

Should be 'jdbc' instead of 'jjdbc':

 torque.database.buildUrl = jdbc:derby:net://localhost/test


However, in future releases of Torque, it is quite probable that
village is
removed, so this will not be problematic any longer.

...

I'll try the embedded driver, which worked great for the torque

tutorial.

One problem I discovered in the tutorial (and that repeats in the

tests)

is Derby doesn't support creating a table that references another table


that doesn't exist yet. For example, this BOOK create statement fails
because the author table doesn't exist yet (this from
trunks/test/test-project/target/sql/bookstore-schema.sql):

CREATE TABLE book
(
   book_id INTEGER NOT NULL,
   isbn VARCHAR(15) NOT NULL,
   author_id INTEGER NOT NULL,
   title VARCHAR(255) NOT NULL,
   PRIMARY KEY(book_id),
   FOREIGN KEY (author_id) REFERENCES author (author_id)
   );

My solution for this for the tutorial was to modify the
src/schema/project-schema.xml to place the BOOK definition at the end,
then it worked great.

-jean



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to