From derby-dev-digest-return-5063-050503w=acadiau.ca@db.apache.org Thu Jun 2 15:52:34 2005 X-Account-Key: account2 Return-Path: X-Sieve: cmu-sieve 2.0 Received: from localhost (localhost [127.0.0.1]) by acadiau.ca (Postfix) with ESMTP id 0BE4E18FCF for <050503w@relay.acadiau.ca>; Thu, 2 Jun 2005 17:52:34 -0300 (ADT) Received: from acadiau.ca ([127.0.0.1]) by localhost (apollo.acadiau.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 40409-01-18 for <050503w@relay.acadiau.ca>; Thu, 2 Jun 2005 17:52:30 -0300 (ADT) Received: from mail.apache.org (hermes.apache.org [209.237.227.199]) by acadiau.ca (Postfix) with SMTP id 08C1C18F86 for <050503w@acadiau.ca>; Thu, 2 Jun 2005 17:52:28 -0300 (ADT) Received: (qmail 20770 invoked by uid 500); 2 Jun 2005 20:52:25 -0000 Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Date: 2 Jun 2005 20:52:25 -0000 Message-ID: <1117745545.20767.ezmlm@db.apache.org> From: derby-dev-digest-help@db.apache.org Delivered-To: responder for derby-dev-digest@db.apache.org To: derby-dev@db.apache.org MIME-Version: 1.0 Content-Type: multipart/digest; boundary=hdgbcnkokcgnbefkffag Subject: derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322 X-Virus-Scanned: by amavisd-new at acadiau.ca Status: RO --hdgbcnkokcgnbefkffag Content-Type: text/plain; charset=us-ascii derby-dev Digest 2 Jun 2005 20:52:25 -0000 Issue 322 Topics (messages 5063 through 5089): Re: Test suite jdbc20 and j9 5063 by: Myrna van Lunteren 5065 by: Daniel John Debrunner Re: Use of DriverManager in tests 5064 by: Daniel John Debrunner 5069 by: Myrna van Lunteren [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server 5066 by: Philip Wilder (JIRA) 5072 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-121) Network Server reading blob/clob data size 5067 by: Philip Wilder (JIRA) 5073 by: Kathey Marsden 5076 by: Army 5088 by: Philip Wilder (JIRA) 5089 by: Philip Wilder (JIRA) Re: looking for opinions on reasonable hardware requirements for tests in standard derby suite 5068 by: Army [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server 5070 by: Philip Wilder (JIRA) 5071 by: Philip Wilder (JIRA) [jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement() 5074 by: Philip Wilder (JIRA) [jira] Commented: (DERBY-17) Network Server Needs to generate CRRTKN on ACCRDB if client does not send it 5075 by: Philip Wilder (JIRA) Re: Implementing Statement.cancel() 5077 by: David Van Couvering [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server 5078 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY" 5079 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-322) Remove resultSetHoldability property from ClientDataSource 5080 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-179) Hibernate bad support 5081 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-132) in place table/index compress which returns space to OS 5082 by: Philip Wilder (JIRA) Re: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver 5083 by: Lance J. Andersen 5085 by: Philip Wilder (JIRA) Re: DerbyNetClient/lang/updatableResultSet fails 5084 by: Mamta Satoor [jira] Updated: (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl 5086 by: Philip Wilder (JIRA) [jira] Updated: (DERBY-156) Delete with alias on column fails 5087 by: Philip Wilder (JIRA) Administrivia: To subscribe to the digest, e-mail: derby-dev-digest-subscribe@db.apache.org To unsubscribe from the digest, e-mail: derby-dev-digest-unsubscribe@db.apache.org To post to the list, e-mail: derby-dev@db.apache.org ---------------------------------------------------------------------- --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5063.ezm" Message-ID: Date: Thu, 2 Jun 2005 11:19:17 -0700 From: Myrna van Lunteren Reply-To: Myrna van Lunteren To: Derby Development Subject: Re: Test suite jdbc20 and j9 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2784_15080630.1117736357392" ------=_Part_2784_15080630.1117736357392 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 6/2/05, Daniel John Debrunner wrote:=20 >=20 >=20 > The test suite jdbc20 currently is not run on j9 (has runwithj9=3Dfalse i= n > the jdbc20.properties file).=20 >=20 > Anyone know why this is? >=20 > The current j9 environment is a full JDK 1.3 environment with JDBC 2.1. >=20 > I tried it out with WCTME 5.7 and jclMax and the tests all pass. >=20 > Dan. >=20 >=20 >=20 I think this must be a left-over of running with an earlier version of j9= =20 which did *not* support jdbc20 functionality. If the tests pass, it's fine. For checks, I ran with wsdd5.6 (j9 2.1), and= =20 all passes with that version too. We don't currently support earlier=20 versions of j9. Shall I make a patch to remove the runwithj9=3Dfalse line from this suite,= or=20 can you - as a committer - do that in passing? Myrna ------=_Part_2784_15080630.1117736357392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On 6/2/05, D= aniel John Debrunner <djd@debr= unners.com> wrote:=20

The test suite jdbc20 curren= tly is not run on j9 (has runwithj9=3Dfalse in
the jdbc20.properties fil= e).=20

Anyone know why this is?

The current j9 environment is a ful= l JDK 1.3 environment with JDBC 2.1.

I tried it out with WCTME 5.7 a= nd jclMax and the tests all pass.

Dan.



I think this must be a left-over of running with an earlier version of= j9 which did *not* support jdbc20 functionality.
If the tests pass, it's fine. For checks, I ran with wsdd5.6 (j9 2.1),= and all passes with that version too. We don't currently support earlier v= ersions of j9.
 
Shall I make a patch to remove the runwithj9=3Dfalse line from this su= ite, or can you - as a committer - do that in passing?
 
Myrna

 
------=_Part_2784_15080630.1117736357392-- --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5065.ezm" Message-ID: <429F4DF9.8030103@debrunners.com> Date: Thu, 02 Jun 2005 11:20:41 -0700 From: Daniel John Debrunner MIME-Version: 1.0 To: Derby Development Subject: Re: Test suite jdbc20 and j9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Myrna van Lunteren wrote: > On 6/2/05, *Daniel John Debrunner* > wrote: > > > The test suite jdbc20 currently is not run on j9 (has runwithj9=false in > the jdbc20.properties file). > > Anyone know why this is? > > The current j9 environment is a full JDK 1.3 environment with JDBC 2.1. > > I tried it out with WCTME 5.7 and jclMax and the tests all pass. > > Dan. > > > > I think this must be a left-over of running with an earlier version of > j9 which did *not* support jdbc20 functionality. > If the tests pass, it's fine. For checks, I ran with wsdd5.6 (j9 2.1), > and all passes with that version too. We don't currently support earlier > versions of j9. > > Shall I make a patch to remove the runwithj9=false line from this suite, > or can you - as a committer - do that in passing? Thanks for running it on 5.6, I was worried what the outcome there might be. I'll address this. Dan. --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5064.ezm" Message-ID: <429F1622.7080306@debrunners.com> Date: Thu, 02 Jun 2005 07:22:26 -0700 From: Daniel John Debrunner MIME-Version: 1.0 To: Derby Development Subject: Re: Use of DriverManager in tests Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Øystein Grøvlen wrote: > When developing a test for Derby-230, I was made aware of that we > should not use the DriverManager directly, but instead use > startJBMS(). However, I see some test (e.g., > store/backupRestore1.java) that uses the DriverManager when shutting > down the database and when doing restore. I am currently working on a > test for Derby-298 that needs to do the same. Is it OK to do it this > way? What restriction does it impose on which environment the test > can be run in? J2ME does not suport DriverManager. This is because the JDBC JSR169 subset only supports javax.sql.DataSource as the connection mechanism. I currently have the test suite running under J2ME with about a 50% pass rate. Many of those failures are due to use of DriverManager, which I will look at fixing in one way or another. So at the momeent I would request anyone to minimize use of DriverManager, but if it is needed then use it. Dan. --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5069.ezm" Message-ID: Date: Thu, 2 Jun 2005 11:39:58 -0700 From: Myrna van Lunteren Reply-To: Myrna van Lunteren To: Derby Development Subject: Re: Use of DriverManager in tests Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2828_25459598.1117737598284" ------=_Part_2828_25459598.1117737598284 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 6/2/05, Daniel John Debrunner wrote:=20 >=20 > =D8ystein Gr=F8vlen wrote: >=20 > > When developing a test for Derby-230, I was made aware of that we > > should not use the DriverManager directly, but instead use > > startJBMS(). However, I see some test (e.g., > > store/backupRestore1.java) that uses the DriverManager when shutting > > down the database and when doing restore. I am currently working on a > > test for Derby-298 that needs to do the same. Is it OK to do it this > > way? What restriction does it impose on which environment the test > > can be run in? >=20 > J2ME does not suport DriverManager. This is because the JDBC JSR169 > subset only supports javax.sql.DataSource as the connection mechanism. >=20 > I currently have the test suite running under J2ME with about a 50% pass > rate. Many of those failures are due to use of DriverManager, which I > will look at fixing in one way or another. >=20 > So at the momeent I would request anyone to minimize use of > DriverManager, but if it is needed then use it. >=20 >=20 > Dan. >=20 >=20 > Before, I mentioned that in RunTest, when running with -Duseprocess=3Dfal= se,=20 a call is made to DriverManager: try=20 { java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=3Dtrue"); }=20 catch (java.sql.SQLException e)=20 { // ignore the errors, they are expected. } I imagine other tests are doing something similar. Without DriverManager,= =20 this of course results in a ClassNotFoundDef error. I spent some time, after Kathey's suggestion on another branch, to use=20 ...functionTests.util.TestUtil to shutdown the database, and I think this= =20 should work as a replacement for using DriverManager.getConnection("jdbc:derby:;shutdown=3Dtrue"). In the case of RunTest, I'm wary of making big waves, so I am thinking of= =20 changing the above section to: try=20 { java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=3Dtrue"); }=20 catch (java.sql.SQLException e)=20 { // ignore the errors, they are expected. } // maybe we're running with a DataSource in J2ME. // then we get an ClassNotFoundDef error on DriverManager.getConnection catch (Throwable th)=20 { Properties attrs =3D new Properties(); attrs.setProperty("shutdownDatabase", "shutdown"); try { DataSource ds =3D TestUtil.getDataSource(attrs); ds.getConnection(); } catch (Throwable ith) { ith.printStackTrace(); } } Any reason why this would not work? Should we remove the DriverManager call= =20 altogether & replace with the DataSource call? Thx, Myrna ------=_Part_2828_25459598.1117737598284 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
On 6/2/05, D= aniel John Debrunner <djd@debr= unners.com> wrote:
=D8ystein Gr=F8vlen wrote:
> When developing a test for Derby-230, I was made aware of that we> should not use the DriverManager directly, but instead use
> startJBMS().  However, I see some test (e.g.,
> st= ore/backupRestore1.java) that uses the DriverManager when shutting
> = down the database and when doing restore.  I am currently working= on a
> test for Derby-298 that needs to do the same.  Is i= t OK to do it this
> way?   What restriction does it impose on which environm= ent the test
> can be run in?

J2ME does not suport DriverManag= er. This is because the JDBC JSR169
subset only supports javax.sql.DataS= ource as the connection mechanism.

I currently have the test suite running under J2ME with about a 50%= pass
rate. Many of those failures are due to use of DriverManager, whic= h I
will look at fixing in one way or another.

So at the momeent = I would request anyone to minimize use of
DriverManager, but if it is needed then use it.


Dan.

=
Before, I mentioned that in RunTest, when running with -Duseprocess=3D= false, a call is made to DriverManager:
   try
   {
    ja= va.sql.DriverManager.getConnection("jdbc:derby:;shutdown=3Dtrue")= ;
   }
   catch (java.sql.SQLException= e)
   {
    // ignore the errors= , they are expected.
   }
I imagine other tests are doing something similar. Without DriverManag= er, this of course results in a ClassNotFoundDef error.
I spent some time, after Kathey's suggestion on another branch, to use= ...functionTests.util.TestUtil to shutdown the database, and I think this = should work as a replacement for using DriverManager.getConnection("jd= bc:derby:<db>;shutdown=3Dtrue"). In the case of RunTest, I'm war= y of making big waves, so I am thinking of changing the above section = to:
 
   try
   {
     &= nbsp;java.sql.DriverManager.getConnection("jdbc:derby:;shutdown=3Dtrue= ");
   } 
   catch (java.sql.= SQLException e)
   {
     //= ignore the errors, they are expected.
   }
   // maybe we're running with a DataSource in J2ME.
&nbs= p;  // then we get an ClassNotFoundDef error on DriverManager.get= Connection
   catch (Throwable th)
   = {
      Properties attrs =3D new Properties();<= br>       attrs.setProperty("shutdownDatabase", "shutdown");
&= nbsp;     try {
      =    DataSource ds =3D TestUtil.getDataSource(attrs);
 &nbs= p;       ds.getConnection();
  &= nbsp;  } catch (Throwable ith) {
     &nbs= p;    ith.printStackTrace();
     }
  &n= bsp;}

Any reason why this would not work? Should we remove the DriverMan= ager call altogether & replace with the DataSource call?
 
Thx,
Myrna
------=_Part_2828_25459598.1117737598284-- --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5066.ezm" Message-ID: <652975208.1117736935603.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:28:55 +0200 (CEST) From: "Philip Wilder (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-213?page=all ] Philip Wilder reassigned DERBY-213: ----------------------------------- Assign To: Philip Wilder (was: Kathey Marsden) > ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server > -------------------------------------------------------------------------------------------------- > > Key: DERBY-213 > URL: http://issues.apache.org/jira/browse/DERBY-213 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Philip Wilder > Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java > > Network Server closes the result set if ResultSet.next() is > called after the last row of the result set. The test code > below throws the following exception. > SQLState: null > Severity: -99999 > Message: Invalid operation: result set closed > com.ibm.db2.jcc.am.SqlException: Invalid operation: result set > closed > at > com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j > ava:3419) > at > com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290) > at > com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277) > at AfterLast.test(AfterLast.java:75) > at AfterLast.main(AfterLast.java:32) > stmt.executeUpdate("CREATE TABLE TAB ( I INT)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(1)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(2)"); > String sql ="SELECT * from tab"; > ps = conn.prepareStatement(sql); > ResultSet rs = ps.executeQuery(); > System.out.println(sql); > while (rs.next()) > System.out.println(rs.getInt(1)); > try { > System.out.println("one more next"); > rs.next(); > } > catch (Exception e) > { > System.out.println("FAIL: next should return false not throw > exception"); > e.printStackTrace(); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5072.ezm" Message-ID: <2032554392.1117736287560.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:18:07 +0200 (CEST) From: "Philip Wilder (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Assigned: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-213?page=all ] Philip Wilder reassigned DERBY-213: ----------------------------------- Assign To: Kathey Marsden If Jira does not support multiple assignees, Philip Wilder can also be considered an assignee. > ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server > -------------------------------------------------------------------------------------------------- > > Key: DERBY-213 > URL: http://issues.apache.org/jira/browse/DERBY-213 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Kathey Marsden > Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java > > Network Server closes the result set if ResultSet.next() is > called after the last row of the result set. The test code > below throws the following exception. > SQLState: null > Severity: -99999 > Message: Invalid operation: result set closed > com.ibm.db2.jcc.am.SqlException: Invalid operation: result set > closed > at > com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j > ava:3419) > at > com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290) > at > com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277) > at AfterLast.test(AfterLast.java:75) > at AfterLast.main(AfterLast.java:32) > stmt.executeUpdate("CREATE TABLE TAB ( I INT)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(1)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(2)"); > String sql ="SELECT * from tab"; > ps = conn.prepareStatement(sql); > ResultSet rs = ps.executeQuery(); > System.out.println(sql); > while (rs.next()) > System.out.println(rs.getInt(1)); > try { > System.out.println("one more next"); > rs.next(); > } > catch (Exception e) > { > System.out.println("FAIL: next should return false not throw > exception"); > e.printStackTrace(); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5067.ezm" Message-ID: <310042330.1117736933976.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:28:53 +0200 (CEST) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-121?page=all ] A B updated DERBY-121: ---------------------- Attachment: derby-121_2.stat derby-121_2.patch Attaching patch to test and resolve this issue. In order to test, I had to create a new suite (separate from "derbyall") since the test case requires more JVM heap size than usual. The actual fix for the problem is as given in the description for this defect--I made that fix in both the Network Server code and in the Derby Client. > Network Server reading blob/clob data size > ------------------------------------------ > > Key: DERBY-121 > URL: http://issues.apache.org/jira/browse/DERBY-121 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Environment: The is a bit shift typo in Network Server reading clob/blob data size > Reporter: Lynh Nguyen > Priority: Minor > Attachments: derby-121_2.patch, derby-121_2.stat > > in DDMReader.java > ... > ... readLengthAndCodePoint() ... { > ... > switch (numberOfExtendedLenBytes) { > case 8: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 64) + > ((buffer[pos++] & 0xff) << 56) + > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 12; > break; > case 6: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 10; > break; > case 4: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 8; > break; > ... > The shift bits should be in order: > 0,8,16,24 > 0,8,16,24,32,40 > 0,8,16,24,32,40,48,56 > This will only affect the larger clob/blob (over 64K ...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5073.ezm" Message-ID: <429F545B.5070307@sbcglobal.net> Date: Thu, 02 Jun 2005 11:47:55 -0700 From: Kathey Marsden MIME-Version: 1.0 To: Derby Development Subject: Re: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit A B (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-121?page=all ] > >A B updated DERBY-121: >---------------------- > > Attachment: derby-121_2.stat > derby-121_2.patch > >Attaching patch to test and resolve this issue. > > Hi Army, I seem to recall that the client also needed the same change in Reply.java. Could you check that? In the test I think we should rename lob64KTable(bl blob(100M); to something more suited to its size. When you repost your patch could you add a comment that I can use as a check-in comment. Could you also change the bug description to have the correct size instead of 64K? Thanks Kathey --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5076.ezm" Message-ID: <429F5705.8030206@sbcglobal.net> Date: Thu, 02 Jun 2005 11:59:17 -0700 From: Army MIME-Version: 1.0 To: Derby Development Subject: Re: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Kathey Marsden wrote: > I seem to recall that the client also needed the same change in > Reply.java. Could you check that? It did, and I think the change is already in the patch (way down at the bottom of the patch). > In the test I think we should rename lob64KTable(bl blob(100M); to > something more suited to its size. Oops, sorry. Yes, I'll rename this. I pulled it from the JIRA entry when I first started writing the test, and forgot to change the name later. > When you repost your patch could you add a comment that I can use as a > check-in comment. Okay. > Could you also change the bug description to have the correct size > instead of 64K? Yep, will do. Army --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5088.ezm" Message-ID: <1629035394.1117745512716.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:51:52 +0200 (CEST) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-121?page=all ] A B updated DERBY-121: ---------------------- Attachment: derby-121_3.patch Modified patch so that lobLengthTests.java uses a table name that correctly indicates the size of the test table we're using. Also, per Kathey M's request, I'm including a "check-in comment" here: ---- 1) Change Network Server and Derby Client code to do correct bit-shifting when processing the length of LOBs that are larger than 2^24 bytes (DERBY-121). 2) Add a new suite, "largeData", for running tests that require extra machine resources, and add the test for DERBY-121 to that suite (because the test for DERBY-121 requires extra heap memory for the server's JVM). ---- > Network Server reading blob/clob data size > ------------------------------------------ > > Key: DERBY-121 > URL: http://issues.apache.org/jira/browse/DERBY-121 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Environment: The is a bit shift typo in Network Server reading clob/blob data size > Reporter: Lynh Nguyen > Assignee: A B > Priority: Minor > Attachments: derby-121_2.stat, derby-121_3.patch > > in DDMReader.java > ... > ... readLengthAndCodePoint() ... { > ... > switch (numberOfExtendedLenBytes) { > case 8: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 64) + > ((buffer[pos++] & 0xff) << 56) + > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 12; > break; > case 6: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 10; > break; > case 4: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 8; > break; > ... > The shift bits should be in order: > 0,8,16,24 > 0,8,16,24,32,40 > 0,8,16,24,32,40,48,56 > This will only affect the larger clob/blob (over 64K ...) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5089.ezm" Message-ID: <1611649751.1117745529432.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:52:09 +0200 (CEST) From: "A B (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-121) Network Server reading blob/clob data size Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-121?page=all ] A B updated DERBY-121: ---------------------- Description: in DDMReader.java ... ... readLengthAndCodePoint() ... { ... switch (numberOfExtendedLenBytes) { case 8: ddmScalarLen = ((buffer[pos++] & 0xff) << 64) + ((buffer[pos++] & 0xff) << 56) + ((buffer[pos++] & 0xff) << 48) + ((buffer[pos++] & 0xff) << 40) + ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 12; break; case 6: ddmScalarLen = ((buffer[pos++] & 0xff) << 48) + ((buffer[pos++] & 0xff) << 40) + ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 10; break; case 4: ddmScalarLen = ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 8; break; ... The shift bits should be in order: 0,8,16,24 0,8,16,24,32,40 0,8,16,24,32,40,48,56 This will only affect a lob if its length requires at least 24 bits--i.e. if the lob has a length of at least 2^24 bytes. was: in DDMReader.java ... ... readLengthAndCodePoint() ... { ... switch (numberOfExtendedLenBytes) { case 8: ddmScalarLen = ((buffer[pos++] & 0xff) << 64) + ((buffer[pos++] & 0xff) << 56) + ((buffer[pos++] & 0xff) << 48) + ((buffer[pos++] & 0xff) << 40) + ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 12; break; case 6: ddmScalarLen = ((buffer[pos++] & 0xff) << 48) + ((buffer[pos++] & 0xff) << 40) + ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 10; break; case 4: ddmScalarLen = ((buffer[pos++] & 0xff) << 32) + ((buffer[pos++] & 0xff) << 16) + ((buffer[pos++] & 0xff) << 8) + ((buffer[pos++] & 0xff) << 0); adjustSize = 8; break; ... The shift bits should be in order: 0,8,16,24 0,8,16,24,32,40 0,8,16,24,32,40,48,56 This will only affect the larger clob/blob (over 64K ...) > Network Server reading blob/clob data size > ------------------------------------------ > > Key: DERBY-121 > URL: http://issues.apache.org/jira/browse/DERBY-121 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Environment: The is a bit shift typo in Network Server reading clob/blob data size > Reporter: Lynh Nguyen > Assignee: A B > Priority: Minor > Attachments: derby-121_2.stat, derby-121_3.patch > > in DDMReader.java > ... > ... readLengthAndCodePoint() ... { > ... > switch (numberOfExtendedLenBytes) { > case 8: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 64) + > ((buffer[pos++] & 0xff) << 56) + > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 12; > break; > case 6: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 48) + > ((buffer[pos++] & 0xff) << 40) + > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 10; > break; > case 4: > ddmScalarLen = > ((buffer[pos++] & 0xff) << 32) + > ((buffer[pos++] & 0xff) << 16) + > ((buffer[pos++] & 0xff) << 8) + > ((buffer[pos++] & 0xff) << 0); > adjustSize = 8; > break; > ... > The shift bits should be in order: > 0,8,16,24 > 0,8,16,24,32,40 > 0,8,16,24,32,40,48,56 > This will only affect a lob if its length requires at least 24 bits--i.e. if the lob has a length of at least 2^24 bytes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5068.ezm" Message-ID: <429F50DF.9010102@sbcglobal.net> Date: Thu, 02 Jun 2005 11:33:03 -0700 From: Army MIME-Version: 1.0 To: Derby Development Subject: Re: looking for opinions on reasonable hardware requirements for tests in standard derby suite Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8bit Øystein Grøvlen wrote: >>>>>>"MM" == Mike Matrigali writes: > > MM> I would still like almost all tests to be included in derbyall, > MM> but it would seem reasonable for there to be a small suite > MM> which hopefully could be set up to be automatically run on > MM> some interval - worst case at least before a release. > > I agree with you. We need a testsuite for long-running tests and > large data volumes. I have a feeling that due to the way we do > testing, the robustness of Derby for large data volumes are not the > best. I know David had some recovery problems when doing a large data > volume test. > I agree, as well. And in fact, the need for such a suite came up when I was working with DERBY-121. The test case that I wrote for DERBY-121 requires a rather large LOB to be passed to Network Server, which means the server JVM needs more heap than usual. While this probably isn't a "large data volume" like what you were envisioning, it nonetheless is a similar sort of thing--namely, it's a test that requires extra machine resources and thus shouldn't be run as part of "derbyall". As part of my patch for DERBY-121, I created a new suite "largeData" that is fairly generic and that can (hopefully) be expanded/extended to help satisfy the requirements described by Mike in this thread. See the following email for that patch and a description of what I did with the new suite: http://thread.gmane.org/gmane.comp.apache.db.derby.devel/4843 And please make comments if you think the new suite could be organized better to fit the needs described in this thread (at least, the "large data volumne" needs). Remember: the new suite is only meant to be a starting place; it's not (yet) intended to satsify all of the large data/long-running test requirements... Army --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5070.ezm" Message-ID: <1004404921.1117736286454.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:18:06 +0200 (CEST) From: "Philip Wilder (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-213?page=all ] Philip Wilder updated DERBY-213: -------------------------------- Attachment: resultset.java Update on the previous resultset.java submission > ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server > -------------------------------------------------------------------------------------------------- > > Key: DERBY-213 > URL: http://issues.apache.org/jira/browse/DERBY-213 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java > > Network Server closes the result set if ResultSet.next() is > called after the last row of the result set. The test code > below throws the following exception. > SQLState: null > Severity: -99999 > Message: Invalid operation: result set closed > com.ibm.db2.jcc.am.SqlException: Invalid operation: result set > closed > at > com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j > ava:3419) > at > com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290) > at > com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277) > at AfterLast.test(AfterLast.java:75) > at AfterLast.main(AfterLast.java:32) > stmt.executeUpdate("CREATE TABLE TAB ( I INT)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(1)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(2)"); > String sql ="SELECT * from tab"; > ps = conn.prepareStatement(sql); > ResultSet rs = ps.executeQuery(); > System.out.println(sql); > while (rs.next()) > System.out.println(rs.getInt(1)); > try { > System.out.println("one more next"); > rs.next(); > } > catch (Exception e) > { > System.out.println("FAIL: next should return false not throw > exception"); > e.printStackTrace(); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5071.ezm" Message-ID: <202260870.1117736285880.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:18:05 +0200 (CEST) From: "Philip Wilder (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-213?page=all ] Philip Wilder updated DERBY-213: -------------------------------- Attachment: Client.java Update to previous client submission. > ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server > -------------------------------------------------------------------------------------------------- > > Key: DERBY-213 > URL: http://issues.apache.org/jira/browse/DERBY-213 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Attachments: Client.java, Create.java, IRCTranscript_June2_2005.txt, Server.java, resultset.java > > Network Server closes the result set if ResultSet.next() is > called after the last row of the result set. The test code > below throws the following exception. > SQLState: null > Severity: -99999 > Message: Invalid operation: result set closed > com.ibm.db2.jcc.am.SqlException: Invalid operation: result set > closed > at > com.ibm.db2.jcc.am.ResultSet.checkForClosedResultSet(ResultSet.j > ava:3419) > at > com.ibm.db2.jcc.am.ResultSet.nextX(ResultSet.java:290) > at > com.ibm.db2.jcc.am.ResultSet.next(ResultSet.java:277) > at AfterLast.test(AfterLast.java:75) > at AfterLast.main(AfterLast.java:32) > stmt.executeUpdate("CREATE TABLE TAB ( I INT)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(1)"); > stmt.executeUpdate("INSERT INTO TAB VALUES(2)"); > String sql ="SELECT * from tab"; > ps = conn.prepareStatement(sql); > ResultSet rs = ps.executeQuery(); > System.out.println(sql); > while (rs.next()) > System.out.println(rs.getInt(1)); > try { > System.out.println("one more next"); > rs.next(); > } > catch (Exception e) > { > System.out.println("FAIL: next should return false not throw > exception"); > e.printStackTrace(); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5074.ezm" Message-ID: <1434208485.1117738252962.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:50:52 +0200 (CEST) From: "Philip Wilder (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Created: (DERBY-333) Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement() Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Malformed if statement in org.apache.derby.impl.drda.Database.getDRDAStatement() -------------------------------------------------------------------------------- Key: DERBY-333 URL: http://issues.apache.org/jira/browse/DERBY-333 Project: Derby Type: Bug Components: Network Server Versions: 10.1.0.0 Environment: ------------------ Java Information ------------------ Java Version: 1.4.2_05 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_05 Java classpath: c:\eclipse\db2jcc.jar;c:\eclipse\db2jcc_license_c.jar;C:\derby\derbyRecent\tools\java\jakarta-oro-2.0.8.jar;c:\derby\derbyRecent\classes;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: 050503w Java user home: C:\Documents and Settings\050503w Java user dir: C:\derby\derbyRecent\classes java.specification.name: Java Platform API Specification java.specification.version: 1.4 --------- Derby Information -------- JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\eclipse\db2jcc.jar] 2.4 - (17) [C:\eclipse\db2jcc_license_c.jar] 2.4 - (17) [C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???) [C:\derby\derbyRecent\classes] 10.1.0.0 alpha - (???) ------------------------------------------------------ Reporter: Philip Wilder Semicolon where it should not be (see the comment): protected DRDAStatement getDRDAStatement(String pkgnamcsn) throws SQLException { // Need to get the short version because resultSets have different // corelation ids. String key = getStmtKey(pkgnamcsn); DRDAStatement newStmt = null; // If our current statement doesn't match,retrieve the statement // and make it current if not null. // if (currentStatement == null || !key.equals(getStmtKey(currentStatement.getPkgnamcsn()))); { newStmt = (DRDAStatement) stmtTable.get(key); } if (newStmt != null) // don't blow away currentStatement if we can't find this one currentStatement = newStmt; else return null; // Set the correct result set. currentStatement.setCurrentDrdaResultSet(pkgnamcsn); return currentStatement; } Solution is to remove the semicolon, all that is needed is a committer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5075.ezm" Message-ID: <1448593521.1117735628861.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 20:07:08 +0200 (CEST) From: "David Van Couvering (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-17) Network Server Needs to generate CRRTKN on ACCRDB if client does not send it Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [ http://issues.apache.org/jira/browse/DERBY-17?page=3Dcomments#action= _66893 ] =20 David Van Couvering commented on DERBY-17: ------------------------------------------ I'd like to understand why JCC cannot guarantee uniqueness. Reading the sp= ec, the CRRTKN is a combination of the specific host and port *of the clien= t* and a long value of the current timestamp, and that's how it's implement= ed in the client code (although for some reason I don't fully fathom it onl= y uses half of the bytes of each part of the IP address). Since each clien= t uses a different TPC-IP port, this value should be unique, even across VM= s where the timestamp might match. The timestamp is just intended to guara= ntee uniqueness within the same VM. =20 That said, if the CRRTKN is null, yes, according to the spec the network se= rver should generate it. But unless I can understand how the CRRTKN genera= ted by the client is not unique across VMs, I don't think it makes sense fo= r the client to stop generating the CRRTKN.=20 > Network Server Needs to generate CRRTKN on ACCRDB if client does not send= it > -------------------------------------------------------------------------= --- > > Key: DERBY-17 > URL: http://issues.apache.org/jira/browse/DERBY-17 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.0.2.0 > Reporter: Ramandeep Kaur > Priority: Minor > > Opening this bug on behalf of Katherine Marsden > -------------------------------------------------------------- > JCC cannot guarantee that the CRRTKN that they send is unique=20 > because it may come from many jvms. > According to the DDM Spec in ACCRDBRM we should generate and=20 > send CRRTKN if it was not sent to us. > crrtkn INSTANCE_OF CRRTKN - Correlation Token > 1810 OPTIONAL > 1811 DFTVAL =C3=A2=C2=80=C2=99=C3=A2=C2=80=C2=99 > 1812 NOTE Source server product-specific value is used. > 1813 This parameter is returned if and only if the > 1814 CRRTKN parameter is not received on > 1815 ACCRDB. --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5077.ezm" Date: Thu, 02 Jun 2005 09:34:14 -0700 From: David Van Couvering Subject: Re: Implementing Statement.cancel() To: Derby Development Message-id: <429F3506.5010204@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I have had similar difficulties finding navigation paths from one object to another within the domain of execution contexts. I have been toying with the idea of putting together one or two UML class diagrams (using an open-source tool, of course :)) to try and show the relationships between all these numerous classes and interfaces. Every time I get in there I have to re-learn how the pieces fit together, and often my internal buffer overflows and I get lost :) It would also be great to document some of the design principles/approaches to this layer of the code, as it's not at all clear through reading the code. I don't have this knowledge, but if someone who does can type something up, I can try and put it into a form that can be posted as a paper to the web site. David Daniel John Debrunner wrote: > Oyvind.Bakksjo@sun.com wrote: > > >>Daniel John Debrunner wrote: >> >> >>>Oyvind.Bakksjo@Sun.COM wrote: >>> >>> >>> >>>>I've been looking at implementing Statement.cancel(), and later, >>>>Statement.setQueryTimeout(). >>> >>> >>> >>>So, quick summary, that method is not suitable for finding the correct >>>StatementContext from EmbedStatement.cancel(). >>> >>>I'll look into how I think you should track down the StatementContext. >>>Dan. >> >> >>Hi Dan, >> >>have you had any time to look into this? > > Not a lot :-( > > I've been thinking about it and there are a couple of issues: > > 1) StatementContexts are created dynamically for the current running > statement > > 2) Derby does not keep references to application JDBC objects below the > JDBC layer. This is to ensure when any JDBC object (e.g. Statement) > moves out of scope for the application, it will be garbage collected and > lead to its closure. > > I wonder if from a StatementContext you can determine the activation > because that would provide the link to the Statement. > > > Dan. > > > --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5078.ezm" Message-ID: <380093409.1117743542496.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:19:02 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-318) SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-318?page=all ] Samuel Andrew McIntyre updated DERBY-318: ----------------------------------------- Fix Version: 10.1.0.0 > SYS.SYSCOLUMN problem with "GENERATED BY DEFAULT" column w/ Network Server > -------------------------------------------------------------------------- > > Key: DERBY-318 > URL: http://issues.apache.org/jira/browse/DERBY-318 > Project: Derby > Type: Bug > Components: Network Server > Versions: 10.1.0.0 > Environment: Derby in Network Server mode with either JCC or Derby Net Client. > Reporter: A B > Fix For: 10.1.0.0 > Attachments: DERBY-318.patch, derbyall_diff.txt > > When connected to the Derby Network Server, if one has a table with a column defined as "GENERATED BY DEFAULT" and then one tries to select the "COLUMNDEFAULT" field from SYS.SYSCOLUMNS, the result is an NPE in the server code that leads to connection deallocation. > I don't know if this is a problem with the "GENERATED BY DEFAULT" feature or if it's a problem with Network Server--more investigation is required. > To reproduce, use ij to connect to a database using Network Server, and then: > ij> create table t1 (i int generated by default as identity); > 0 rows inserted/updated/deleted > ij> select columndefault from sys.syscolumns; > COLUMNDEFAULT > ---------------------------------------------------------------------------------------------------- > ---------------------------- > null > java.lang.NullPointerException > at org.apache.derby.impl.drda.DRDAConnThread.writeFdocaVal(DRDAConnThread.java:6550) > at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.java:5973) > at org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnThread.java:5796) > at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:595) > at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:226) > agentThread[DRDAConnThread_2,5,main] > ERROR 58009: Execution failed due to a distribution protocol error that caused deallocation of the conversation. A DRDA Data Stream Syntax Error was detected. Reason: 0x3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5079.ezm" Message-ID: <23340853.1117743541645.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:18:57 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-308) Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY" Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-308?page=all ] Samuel Andrew McIntyre updated DERBY-308: ----------------------------------------- Version: 10.1.0.0 Fix Version: 10.1.0.0 > Modify dblook to support "GENERATED BY DEFAULT AS IDENTITY" > ----------------------------------------------------------- > > Key: DERBY-308 > URL: http://issues.apache.org/jira/browse/DERBY-308 > Project: Derby > Type: Sub-task > Versions: 10.1.0.0 > Reporter: Tomohito Nakayama > Assignee: Tomohito Nakayama > Fix For: 10.1.0.0 > Attachments: DERBY-308.patch > > The Derby "dblook" utility needs to support "GENERATED BY DEFAULT AS IDENTITY". > This issue was notified in next mail. > http://article.gmane.org/gmane.comp.apache.db.derby.devel/4096 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5080.ezm" Message-ID: <1475959133.1117743565456.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:19:25 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-322) Remove resultSetHoldability property from ClientDataSource Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-322?page=all ] Samuel Andrew McIntyre updated DERBY-322: ----------------------------------------- Fix Version: 10.1.0.0 > Remove resultSetHoldability property from ClientDataSource > ---------------------------------------------------------- > > Key: DERBY-322 > URL: http://issues.apache.org/jira/browse/DERBY-322 > Project: Derby > Type: Bug > Components: JDBC, Network Client > Versions: 10.1.0.0 > Reporter: Daniel John Debrunner > Fix For: 10.1.0.0 > > ClientDataSource (through ClientBaseDataSource) implements a Java Bean property resultSetHoldability which is not documented in the functional spec at. > http://incubator.apache.org/derby/papers/DerbyClientSpec.html > JDBC provides standard ways to set the holdability of ResultSets, so a non-standard separate mechanism is not required. The property and associated code needs to be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5081.ezm" Message-ID: <509312037.1117743570122.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:19:30 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-179) Hibernate bad support Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable [ http://issues.apache.org/jira/browse/DERBY-179?page=3Dall ] Samuel Andrew McIntyre updated DERBY-179: ----------------------------------------- Priority: Major (was: Blocker) > Hibernate bad support > --------------------- > > Key: DERBY-179 > URL: http://issues.apache.org/jira/browse/DERBY-179 > Project: Derby > Type: Bug > Components: SQL > Versions: 10.0.2.1 > Environment: SUN JDK 1.4 > Hibernate 2.1.8 > Reporter: dju dju > > When trying to use Derby with the Hibernate basic example (auction system= - ant eg) I get the following error . I have being using the Derby Dialect= posted at http://opensource.atlassian.com/projects/hibernate/browse/HB-122= 4 > Here is the error message: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > [java] Hibernate: select * from ( select rownumber() over(order by = auctionite0_.ends desc) as rownumber_, auctionite0_.id as id0_, bids1_.id a= s id1_, user2_.id as id2_, auctionite0_.description as descript2_0_, auctio= nite0_.ends as ends0_, auctionite0_.condition as condition0_, auctionite0_.= seller as seller0_, auctionite0_.successfulBid as successf6_0_, bids1_.isBu= yNow as isBuyNow1_, bids1_.amount as amount1_, bids1_.datetime as datetime1= _, bids1_.bidder as bidder1_, bids1_.item as item1_, user2_.userName as use= rName2_, user2_."password" as y3_2_, user2_.email as email2_, user2_.firstN= ame as firstName2_, user2_."initial" as y6_2_, user2_.lastName as lastName2= _, bids1_.item as item__, bids1_.id as id__ from AuctionItem auctionite0_ l= eft outer join Bid bids1_ on auctionite0_.id=3Dbids1_.item left outer join = AuctionUser user2_ > on bids1_.bidder=3Duser2_.id order by auctionite0_.ends desc ) as temp_ = where rownumber_ <=3D ? > [java] 15:16:29,959 WARN JDBCExceptionReporter:57 - SQL Error: -1, = SQLState: 42X01 > [java] 15:16:29,959 ERROR JDBCExceptionReporter:58 - DB2 SQL error: = SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount > ered "(" at line 1, column 40=C2=B642X01 > [java] 15:16:29,990 WARN JDBCExceptionReporter:57 - SQL Error: -1, = SQLState: 42X01 > [java] 15:16:29,990 ERROR JDBCExceptionReporter:58 - DB2 SQL error: = SQLCODE: -1, SQLSTATE: 42X01, SQLERRMC: Encount > ered "(" at line 1, column 40=C2=B642X01 > [java] net.sf.hibernate.exception.SQLGrammarException: Could not exe= cute query > [java] at net.sf.hibernate.exception.SQLStateConverter.convert(S= QLStateConverter.java:58) > [java] at net.sf.hibernate.exception.JDBCExceptionHelper.convert= (JDBCExceptionHelper.java:29) > [java] at net.sf.hibernate.impl.SessionImpl.convert(SessionImpl.= java:4131) > [java] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.jav= a:1557) > [java] at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:49= ) > [java] at org.hibernate.auction.Main.viewAllAuctionsSlow(Main.ja= va:86) > [java] at org.hibernate.auction.Main.main(Main.java:366) > Can you help with this?=20 --=20 This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5082.ezm" Message-ID: <964815814.1117743562450.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:19:22 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-132) in place table/index compress which returns space to OS Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-132?page=all ] Samuel Andrew McIntyre updated DERBY-132: ----------------------------------------- Fix Version: 10.1.0.0 > in place table/index compress which returns space to OS > ------------------------------------------------------- > > Key: DERBY-132 > URL: http://issues.apache.org/jira/browse/DERBY-132 > Project: Derby > Type: Improvement > Components: Store > Versions: 10.1.0.0 > Reporter: Mike Matrigali > Assignee: Mike Matrigali > Fix For: 10.1.0.0 > > Each derby table or index is stored in a separate file. Space from > deleted rows is eventually reclaimed within the file as is used for > subsequent inserts into the same file. That space is not returned to > the OS unless the user calls the SYSCS_UTIL.SYSCS_COMPRESS_TABLE > system procedure. That procedure will return the unused space in > the tables and indexes to the OS. It gets an exclusive lock on the > table, copies all rows in the indexes and the base table into new > compressed files and delete the old files. Prior to jdk 1.4 this was > the only way to return space from a file to the OS. > In jdk 1.4 RandomAccessFile was enhanced to allow the truncation of a > file, which would return the space at the "end" of the file back to > the OS. In order to take advantage of this new feature a new > compress feature is needed in derby. > The assumption is that this work will be used in future work which will > automatically schedule this job and others in background, with no > interaction needed from the dba. The 1st phase of this work will > simply build a procedure that will do the work. The 2nd phase will > be to look into scheduling the procedure automatically as part of > the current background post commit processing. Longer term it would > be best if this fit into a new background task monitor, which could > schedule larger background tasks balanced against the other priorities > of the system. These tasks might include: this new online compress, > automatic statistics gathering, more proactive deleted row reclamation, .... > The proposed feature will reorganize base tables and indexes, moving > empty pages to the "end". It will release space back to the operating > system when it has created a chunk of empty pages at the end of the > file. It will be designed to run in background, and will lock resources > of the table for as short a time as possible so that it can iteratively > process the table. > To reclaim space in the heap, it will scan the heap in page reverse order. > It will get a short term table lock, process all the rows on a page, and > then commit that transaction releasing the lock. The commit will be > optimized like other internal transactions, and will not need to wait > for a synchonized write. Each row moved, will require all the index > entries for that row to also be updated. While doing the processing it > will also take care of processing committed deleted rows. When space > is free at the end of the table it will be freed back to the operating > system, using the RandomAccessFile.setLength() interface. > To reclaim space in the btree, data on pages will be moved rather than > rows. Data from pages at the end of the file will be moved to free > smaller numbered pages. Again short term table locks will be required, > and the operation will look similar to the current btree merge operations > already implemented. Again when a chunk of pages is free at the end of > the file, they will be returned to the OS using the same mechanism as > the heap. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5083.ezm" Date: Thu, 02 Jun 2005 16:20:38 -0400 From: "Lance J. Andersen" Subject: Re: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver To: "Samuel Andrew McIntyre (JIRA)" Message-id: <429F6A16.6010708@sun.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_GcucD6bYZU5WiaoeQQvDCg)" This is a multi-part message in MIME format. --Boundary_(ID_GcucD6bYZU5WiaoeQQvDCg) Content-type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: 7BIT Yes I am. I just had to put everything on hold for a bit while i got the JDBC 4.0 spec to early draft review. I just submitted it today. So i will get back to this now. -Lance Samuel Andrew McIntyre (JIRA) wrote: > [ http://issues.apache.org/jira/browse/DERBY-247?page=all ] > >Samuel Andrew McIntyre updated DERBY-247: >----------------------------------------- > > Fix Version: 10.1.0.0 > >Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me. > > > >>Network Server demo program should support Derby network client driver >>---------------------------------------------------------------------- >> >> Key: DERBY-247 >> URL: http://issues.apache.org/jira/browse/DERBY-247 >> Project: Derby >> Type: Improvement >> Components: Demos/Scripts >> Versions: 10.1.0.0 >> Reporter: Samuel Andrew McIntyre >> Assignee: Lance Andersen >> Priority: Minor >> Fix For: 10.1.0.0 >> >> > > > >>Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver. >> >> > > > --Boundary_(ID_GcucD6bYZU5WiaoeQQvDCg) Content-type: text/html; charset=UTF-8 Content-transfer-encoding: 8BIT Yes I am.  I just had to put everything on hold for a bit while i got the JDBC 4.0 spec to early draft review.  I just submitted it today.

So i will get back to this now.

-Lance

Samuel Andrew McIntyre (JIRA) wrote:
     [ http://issues.apache.org/jira/browse/DERBY-247?page=all ]

Samuel Andrew McIntyre updated DERBY-247:
-----------------------------------------

    Fix Version: 10.1.0.0

Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me.

  
Network Server demo program should support Derby network client driver
----------------------------------------------------------------------

         Key: DERBY-247
         URL: http://issues.apache.org/jira/browse/DERBY-247
     Project: Derby
        Type: Improvement
  Components: Demos/Scripts
    Versions: 10.1.0.0
    Reporter: Samuel Andrew McIntyre
    Assignee: Lance Andersen
    Priority: Minor
     Fix For: 10.1.0.0
    

  
Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver.
--Boundary_(ID_GcucD6bYZU5WiaoeQQvDCg)-- --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5085.ezm" Message-ID: <1538177287.1117743533766.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:18:53 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-247) Network Server demo program should support Derby network client driver Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-247?page=all ] Samuel Andrew McIntyre updated DERBY-247: ----------------------------------------- Fix Version: 10.1.0.0 Lance, are you going to work on the demo part of this bug? If not, feel free to assign it to me. > Network Server demo program should support Derby network client driver > ---------------------------------------------------------------------- > > Key: DERBY-247 > URL: http://issues.apache.org/jira/browse/DERBY-247 > Project: Derby > Type: Improvement > Components: Demos/Scripts > Versions: 10.1.0.0 > Reporter: Samuel Andrew McIntyre > Assignee: Lance Andersen > Priority: Minor > Fix For: 10.1.0.0 > > Currently, the Network Server demo programs require the IBM Universal JDBC Driver (JCC) for client functionality. The demo should be enhanced to also support using the Derby client driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5084.ezm" Message-ID: Date: Thu, 2 Jun 2005 13:23:38 -0700 From: Mamta Satoor Reply-To: Mamta Satoor To: Derby Development Subject: Re: DerbyNetClient/lang/updatableResultSet fails Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2140_5614590.1117743818824" ------=_Part_2140_5614590.1117743818824 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I am trying to understand the reasons behind updatableResultset test=20 failure when using DerbyNetClient. Following is what I have found so far. Satheesh made a checkin on May 25th (revision 178519) to the master file= =20 DerbyNetClient/updatableResultSet.out which was as follows +++=20 incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTes= ts/master/DerbyNetClient/updatableResultSet.out Wed May 25 12:39:51 2005 @@ -307,14 +307,14 @@ delete using first resultset attempt to send deleteRow on the same row through a different resultset=20 should throw an exception SQL State : XCL08 -Got expected exception Cursor 'SQL_CURLH000C51' is not on a row. +Got expected exception Cursor 'SQL_CURLH000C52' is not on a row. Move to next row in the 2nd resultset and then delete using the second=20 resultset Positive Test11 - setting the fetch size to > 1 will be ignored by updatabl= e=20 resultset. Same as updatable cursors Notice the Fetch Size in run time statistics output. 1 ----- Statement Name: - SQL_CURLH000C54 + SQL_CURLH000C55 Statement Text: SELECT * FROM t1 FOR UPDATE of c1 Parse Time: 0 On May 26th, Bernt reported a diff which is reverse of master update done b= y=20 Satheesh. Checkin from today (revision 179592) submitted by David seems to= =20 bring the master back to the state prior to Satheesh's checkin.=20 Also, Bernt, I looked at=20 http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-178= 249.htmland the reason you didn't see the failure on Linux 2.4.19 and jdk1.4.2_08 I think is because the test never got run on that=20 machine for some reason. In the list of tests that ran as part of=20 derbynetclientmats on Linux 2.4.19 and jdk1.4.2_08, I don't see=20 updatableResultset test in there. Let me know if I have missed anything. Bu= t=20 if I am right, then we don't need updatableResultSet_sed.properties since w= e=20 should get same cursor name irrespective of different platforms.=20 The only question I have is why did Satheesh need to change the master? I a= m=20 running with classes and maybe there is something that shows up only with= =20 the jar files. Satheesh, please let me know if there is an environment that= =20 I have not tested which required the master update. thanks, Mamta On 5/26/05, Bernt M. Johnsen wrote:=20 When running derbyall, DerbyNetClient/lang/updatableResultSet fails > the following way: >=20 > *** Start: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26=20 > 23:12:55 *** > Initialize for framework: DerbyNetClient > java -ms16777216 -mx33554432 - > Dderby.system.home=3D/export/home/tmp/Derby/test/DerbyNetClient/updatable= ResultSet - > Djava.security.manager -Djava.security.policy=3D/export/home/tmp/Derby/te= st/nwsvr.policy - > Dcsinfo.codebase=3D/export/home/tmp/Derby/ trunk/jars/sane - > Dcsinfo.serverhost=3Dlocalhost -Dcsinfo.trustedhost=3Dlocalhost org=20 > .apache.derby.drda.NetworkServerControl start > Attempt to shutdown framework: DerbyNetClient > 310 del > < Got expected exception Cursor 'SQL_CURLH000C52' is not on a row. > 310a310 > > Got expected exception Cursor 'SQL_CURLH000C51' is not on a row. > 317 del > < SQL_CURLH000C55 > 317a317 > > SQL_CURLH000C54 > Test Failed. > *** End: updatableResultSet jdk1.4.2_02 DerbyNetClient 2005-05-26 23:13:2= 2=20 > *** >=20 > (Same error with 1.5 and 1.3) >=20 > I'm running with Linux 2.6.11. What I find strange, is that when I > inspect the test failures in >=20 > http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-1= 78249.html > I see that the same test fails in the same way on all platforms, > with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08 >=20 > Comment anynone? > -- > Bernt Marius Johnsen, Database Technology Group, > Sun Microsystems, Trondheim, Norway > ------=_Part_2140_5614590.1117743818824 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Hi,
 
I am trying to understand the reasons behind updatableResultset t= est failure when using DerbyNetClient. Following is what I have found = so far.
 
Satheesh made a checkin on May 25th (revision 178519) to the master fi= le DerbyNetClient/updatableResultSet.out which was as follows
+++ incubator/derby/code/trunk/java/testing/org/apache/derbyTesting/fu= nctionTests/master/DerbyNetClient/updatableResultSet.out Wed May 25 12:39:5= 1 2005
@@ -307,14 +307,14 @@
 delete using first resultset
&n= bsp;attempt to send deleteRow on the same row through a different resultset= should throw an exception
 SQL State : XCL08
-Got expected exception Cursor 'SQL_CURLH000= C51' is not on a row.
+Got expected exception Cursor 'SQL_CURLH000C52' i= s not on a row.
 Move to next row in the 2nd resultset and then del= ete using the second resultset
 Positive Test11 - setting the fetch size to > 1 will be ignore= d by updatable resultset. Same as updatable cursors
 Notice the Fet= ch Size in run time statistics output.
 1
 -----
 S= tatement Name:
-       SQL_CURLH000C54
+       SQL_CURLH000C55
 Statement Text:
&nbs= p;      SELECT * FROM t1 FOR UPDATE of c1
 Parse Tim= e: 0

On May 26th, Bernt reported a diff which is reverse of master u= pdate done by Satheesh. Checkin from today (revision 179592) submitted= by David seems to bring the master back to the state prior to Satheesh's c= heckin.  
 
Also, Bernt, I looked at http://www.multinet.no/~= solberg/public/Apache/Derby/Limited/testSummary-178249.html  and the reason you didn't see the failure on Linux 2.4.19 and jdk= 1.4.2_08 I think is because the test never got run on that machine for some= reason. In the list of tests that ran as part of derbynetclientmats on Lin= ux=20 2.4.19 and jdk1.4.2_08, I don't see updatableResultset test in there. = Let me know if I have missed anything. But if I am right, then we don't nee= d updatableResultSet_sed.properties since we&n= bsp;should get same cursor name irrespective of different platfor= ms. 
The only question I have is why did Satheesh n= eed to change the master? I am running with classes and maybe there is some= thing that shows up only with the jar files. Satheesh, please let me know i= f there is an environment that I have not tested which required the master = update.
 
thanks,
Mamta
 
On 5/26/05, Bernt M. Johnsen=
 <Bernt.Johnsen@sun.com=
> wrote:
When running derbyall, DerbyNetC= lient/lang/updatableResultSet fails
the following way:

*** Start:= updatableResultSet=20 jdk1.4.2_02 DerbyNetClient 2005-05-26 23:12:55 ***
Initialize for framew= ork: DerbyNetClient
java -ms16777216 -mx33554432 -Dderby.system.home=3D/= export/home/tmp/Derby/test/Der byNetClient/updatableResultSet -Djava.securi= ty.manager -Djava.security.policy=3D/e xport/home/tmp/Derby/test/nwsvr.policy -Dcsinf= o.codebase=3D/export/home/tmp/Derby/ trunk/jars/sane -Dcsinfo.serverhost=3D= localhost -Dcsinfo.trustedhost=3Dlocalhost org .apache.derby.drda.NetworkSe= rverControl start
Attempt to shutdown framework: DerbyNetClient
310 del
< Got ex= pected exception Cursor 'SQL_CURLH000C52' is not on a row.
310a310
&g= t; Got expected exception Cursor 'SQL_CURLH000C51' is not on a row.
317 del
<       SQL_CURLH000C55
317a= 317
>       SQL_CURLH000C54
Test Fai= led.
*** End:   updatableResultSet jdk1.4.2_02 DerbyNetClient = 2005-05-26 23:13:22 ***

(Same error with 1.5 and 1.3)

I'm running with Linux 2.6.11. What I find strange, is that when I
inspe= ct the test failures in
http://www.multinet.no/~sol= berg/public/Apache/Derby/Limited/testSummary-178249.html
I see that the same test fails in the same way on all platforms,with the exception of the test run on a Linux 2.4.19 and jdk1.4.2_08
Comment anynone?
--
Bernt Marius Johnsen, Database Technology Group= ,
Sun Microsystems, Trondheim, Norway

------=_Part_2140_5614590.1117743818824-- --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5086.ezm" Message-ID: <1657113363.1117743543531.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:19:03 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-205?page=all ] Samuel Andrew McIntyre updated DERBY-205: ----------------------------------------- Fix Version: 10.1.0.0 > Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl > ----------------------------------------------------------------------------- > > Key: DERBY-205 > URL: http://issues.apache.org/jira/browse/DERBY-205 > Project: Derby > Type: Task > Components: Network Server > Versions: 10.1.0.0 > Reporter: Kathey Marsden > Assignee: Dag H. Wanvik > Priority: Trivial > Fix For: 10.1.0.0 > Attachments: 205b-rev1.diff, 205b-rev1.stat > > For historical reasons the class DB2jServerImpl, which implements the public NetworkServerControl interface is inappropriately named. It should be renamed to NetworkServerControlImpl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag Content-Type: message/rfc822 Content-Disposition: inline; filename="derby-dev_5087.ezm" Message-ID: <877308444.1117744859583.JavaMail.jira@ajax.apache.org> Date: Thu, 2 Jun 2005 22:40:59 +0200 (CEST) From: "Samuel Andrew McIntyre (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Updated: (DERBY-156) Delete with alias on column fails Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit [ http://issues.apache.org/jira/browse/DERBY-156?page=all ] Samuel Andrew McIntyre updated DERBY-156: ----------------------------------------- Version: 10.0.2.1 10.0.2.0 10.0.2.2 10.1.0.0 Fix Version: 10.1.0.0 Marking as Fix in 10.1.0.0 as a patch has been submitted by Shreyas Kaushik and is in review. > Delete with alias on column fails > --------------------------------- > > Key: DERBY-156 > URL: http://issues.apache.org/jira/browse/DERBY-156 > Project: Derby > Type: New Feature > Components: SQL > Versions: 10.0.2.1, 10.0.2.0, 10.0.2.2, 10.1.0.0 > Reporter: Bernd Ruehlicke > Priority: Critical > Fix For: 10.1.0.0 > > DELETE FROM MY_TABLE x WHERE x.MY_COLUMN='value'; > fails with > ERROR 42X01: Syntax error: Encountered "x" at line 1, column 24 > This is the core of the problem. I found it form a more complicated statement but it cooks down to that this should work but dose not. > B-) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --hdgbcnkokcgnbefkffag--