date:20060125




Three months ago, we shelved this topic, promising to return to it
later. I would like to reach consensus on this problem now. In a
nutshell: JDBC4 introduces new methods whose signatures contain
generics. Because of this, DataSource implementations can't satisfy both
the JDBC3 and JDBC4 contracts.
   



So that's not quite true, a JDBC 4.0 DataSource implementation does
satisfy both JDBC 4.0 and JDBC 3.0. I've been looking at if it would be
possible to have a single implementation that worked in both. Ie. would
the reference to new classes and the generics absolutely make the class
not work in JDBC 3.0. Most likely yes, but it's worth throwing out there.
 

Generics can be compiled jdk 1.5 or higher. And class generated with 
jdk1.5 or higher are not

compatible with the older vm s.

anurag

Re: [jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

2006-01-25 Thread Knut Anders Hatlen

Bryan Pendleton (JIRA) derby-dev@db.apache.org writes:

  [ http://issues.apache.org/jira/browse/DERBY-491?page=all ]

 Bryan Pendleton updated DERBY-491:
 --

 Attachment: svn_jan_24_2006.diff

 Updated patch, against latest trunk. I added a few additional
 comments to this patch to try to explain the changes more clearly,
 and also I added a reference to this bug entry to help the reader
 find more information. Now that DERBY-125 has been committed
 (thanks!), the regression test passes cleanly, and I have also run
 the entire derbyall suite with this patch.

 I think that this patch proposal is now ready for review. Kathey,
 Army, other interested reviewers, please have a look and tell me
 what you think!

Hi Bryan,

I read through your patch, ran derbynetclientmats and derbynetmats
successfully, and verified that the test case failed without your
patch (actually, it didn't fail, it just hung until I got bored and
killed the test).

The changes seem correct to me, they are well documented and the test
case looks good. I have no complaints at all about the patch.

+1 to committing this patch.

-- 
Knut Anders

Re: Features of the JUnit test execution harness

2006-01-25 Thread Bernt M. Johnsen

 Daniel John Debrunner wrote (2006-01-24 20:23:27):
 The other issue is that we have a great opportunity to start out with
 JUnit tests that follow a consistent pattern and provide a great example
 for others to follow. 

+1

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway


pgpVWaBm3AABa.pgp
Description: PGP signature

Re: [jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

2006-01-25 Thread Bernt M. Johnsen

I'll have a look at it and possibly commit it

 Knut Anders Hatlen wrote (2006-01-25 09:59:36):
 Bryan Pendleton (JIRA) derby-dev@db.apache.org writes:
 
   [ http://issues.apache.org/jira/browse/DERBY-491?page=all ]
 
  Bryan Pendleton updated DERBY-491:
  --
 
  Attachment: svn_jan_24_2006.diff
 
  Updated patch, against latest trunk. I added a few additional
  comments to this patch to try to explain the changes more clearly,
  and also I added a reference to this bug entry to help the reader
  find more information. Now that DERBY-125 has been committed
  (thanks!), the regression test passes cleanly, and I have also run
  the entire derbyall suite with this patch.
 
  I think that this patch proposal is now ready for review. Kathey,
  Army, other interested reviewers, please have a look and tell me
  what you think!
 
 Hi Bryan,
 
 I read through your patch, ran derbynetclientmats and derbynetmats
 successfully, and verified that the test case failed without your
 patch (actually, it didn't fail, it just hung until I got bored and
 killed the test).
 
 The changes seem correct to me, they are well documented and the test
 case looks good. I have no complaints at all about the patch.
 
 +1 to committing this patch.
 
 -- 
 Knut Anders
 

-- 
Bernt Marius Johnsen, Database Technology Group, 
Staff Engineer, Technical Lead Derby/Java DB
Sun Microsystems, Trondheim, Norway


pgpmh9QJN3CNJ.pgp
Description: PGP signature

[jira] Updated: (DERBY-796) jdbc 4.0 specific Blob and Clob method support

2006-01-25 Thread V.Narayanan (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-796?page=all ]

V.Narayanan updated DERBY-796:
--

Attachment: lob_2.diff

I have changed it to work in the same pattern as in EmbedPreparedStatement 
(i.e.)  it does a 
throw newSQLException(SQLState.LANG_INVALID_COLUMN_LENGTH);
thanx
Narayanan


 jdbc 4.0 specific Blob and Clob method support
 --

  Key: DERBY-796
  URL: http://issues.apache.org/jira/browse/DERBY-796
  Project: Derby
 Type: New Feature
   Components: JDBC
 Versions: 10.2.0.0
  Environment: jdbc 4.0 on all platforms
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: lob.diff, lob_1.diff, lob_2.diff



-- 
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

[jira] Closed: (DERBY-825) writeSQLCAGRP() should use byte[] constants instead of Strings where feasible

2006-01-25 Thread Dyre Tjeldvoll (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-825?page=all ]
 
Dyre Tjeldvoll closed DERBY-825:



Committed by Bernt Johnsen

 writeSQLCAGRP() should use byte[] constants instead of Strings where feasible
 -

  Key: DERBY-825
  URL: http://issues.apache.org/jira/browse/DERBY-825
  Project: Derby
 Type: Sub-task
   Components: Network Server, Performance
 Reporter: Dyre Tjeldvoll
 Assignee: Dyre Tjeldvoll
 Priority: Minor
  Attachments: derby-825.diff, derby-825.stat, derbynetclientmats_report.txt

 writeSQLCAGRP() writes Strings into the message being built. Profiling shows 
 that it is more expensive to write a String than a byte[] because the String 
 must be converted to UTF8. writeSQLCAGRP() writes 5 bytes for SQLState, and 
 this is done by either writing a String constant, or the return value from 
 SQLException.getSQLState(). For the common case where there is no exception 
 (SQLState = 5xspace), or the exception is a dummy exception (SQLState=0 
 or 02000, End of Data), this is wasteful because the String has to be 
 converted to byte[] each time, and in the case of the dummy exception, a new 
 String object will be created each time getSQLState() is called, even if the 
 exception object is the same (there is no caching, which is reasonable since 
 exceptions are meant to be thrown, not kept around for a long time).
 A solution is to keep the commonly used SQLStates as byte[] constants that 
 can be inserted into the message with writeBytes().
 If writeSQLCAGRP() is called with no SQLException (null) there is no attempt 
 to put an internationalized error message into the outgoing message (The 
 third argument to writeSQLCAXGRP() is null). This is reasonable, but the same 
 optimization is not done when the exception is one of the dummy exceptions 
 mentioned previously. In this case an internationalized version of the 
 message End of Data is constructed and inserted into the message.  It would 
 be better to call writeSQLCAXGRP(..,null,..) in this case as well, since it 
 isn't needed by the client in this case.
 Finally, writeSQLCAERRWARN() uses writeScalarPaddedBytes() to write values 
 that also can be stored as byte[] constants, and written faster with 
 writeBytes()
  

-- 
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

Re: [jira] Updated: (DERBY-326) Improve streaming of large objects for network server and client

2006-01-25 Thread TomohitoNakayama


Hello Bryan.



This is very surprising, is it not? Are you saying that your
conclusion is that there is very little performance benefit to
the DERBY-326 change? Or am I misunderstanding your comment? 


No. I has not concluded anything yet :I

These test (and your comment :) ) touched off me to think
that we need to cocnsider how to measure the performance of streaming lob.

I think the measurement should be done in next 2 points at least.

1: Stability of performance.
See the influence of long run.

2: Performance for volume.
See the influence of size of  binary to be streamed.

3: Difference in type of LOB
See the influence of type of LOB, BLOB or CLOB.


If you noticed any other, please notify me.


Best regards.

--
/*

   Tomohito Nakayama
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

   Naka
   http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/

[jira] Updated: (DERBY-100) Add support for insert functionality using JDBC 2.0 updatable resultset apis

2006-01-25 Thread Fernanda Pizzorno (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-100?page=all ]

Fernanda Pizzorno updated DERBY-100:


Attachment: DERBY-100-2.diff
DERBY-100-2.stat

Thank you for looking into my previous patch.

In this new patch I have:
 * changed moveToInsertRow in 
java/engine/org/apache/derby/impl/jdbc/EmbedResultSet.java so that it will not 
create a new blank row each time
 * changed the sqlState I have added from CANNOT_INSERT_AT_CURRENT_POSITION to 
NOT_POSITIONED_ON_INSERT_ROW
 * changed the tests so that they will print sqlState and message for all 
exceptions and walk down the SQLException chain
 * added some more tests
 * changed the behavior of insertRow when no updateXXX has been called before 
insertRow is called. It now inserts a row with the row's default values.

Can someone please review this patch?

I have not updated the canon for updatableResultSet.java under j9_13 and 
DerbyNet.

I have successfully run derbyall.

 Add support for insert functionality using JDBC 2.0 updatable resultset apis
 

  Key: DERBY-100
  URL: http://issues.apache.org/jira/browse/DERBY-100
  Project: Derby
 Type: New Feature
   Components: JDBC
 Versions: 10.1.1.0
 Reporter: Mamta A. Satoor
 Assignee: Fernanda Pizzorno
  Attachments: DERBY-100-2.diff, DERBY-100-2.stat, DERBY-100.diff, 
 DERBY-100.stat

 The JDBC 2.0 API introduced the ability to update/delete/insert rows from a 
 resultset using methods in the Java programming language rather than having 
 to send an SQL command. This Jira entry is to track the insert rows 
 functionality using JDBC 2.0 apis.

-- 
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

Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver




-1
The use of InternalDriver.activeDriver() to obtain a factory exposes Derby to 
potential NullPointerExceptions in a shutdown or error on boot situation. I see 
that you saw one in your testing as you have a comment on that in the shutdown 
code.  Such NPEs will hide the real error from users, making Derby harder to 
use.

I think the solution is to move some of the code from 
java/engine/org/apache/derby/impl/jdbc/Util.java to be factory methods  on 
InternalDriver. or methods on EmbedConnection or EmbedConnectionChild. I think 
you will find that most, if not all, cases these static Util methods are called 
from a JDBC implementation object which has a reference to its InternalDriver 
factory. Such a change would then remove the need for special code in the 
shutdown case. Basically this move to a factory based allocation for 
SQLException obejcts should make the Util class go away.

Also the new patch is missing the test code.

 

I checked the classes calling using Util to get the SQLException either 
already have the reference of InternalDriver or they can be easily 
modified to have this reference. There appears to be 1 problem class 
EmbedResultSetMetaData.


EmbedResultSetMetaData is being instantiated staticly from many classes 
(eg  org.apache.derby.diag.StatementDuration, StatementCache). I am not 
sure if its safe to assume that InternalDriver variable will be 
initialized before these classes are loaded. Same problem will exist if 
we use EmbedConnection or EmbedConnectionChild for generating the exception.


Another potential place to convert the old exception to newer one was 
handleException in EmbedConnection. Most of the method use this method 
to do cleanup before throwing back the exception. But this won't handle 
connection related exception (connection doesn't exist, class 08)


anurag

[jira] Commented: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements

2006-01-25 Thread Daniel John Debrunner (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-866?page=comments#action_12363958 ] 

Daniel John Debrunner commented on DERBY-866:
-

What's the purpose of returning the password column in the table/vti SYSUSERS?

 BUILT-IN Derby User Management (DDL) Enhancements
 -

  Key: DERBY-866
  URL: http://issues.apache.org/jira/browse/DERBY-866
  Project: Derby
 Type: Improvement
   Components: Security
 Versions: 10.2.0.0
 Reporter: Francois Orsini
  Fix For: 10.2.0.0
  Attachments: Derby_User_Enhancement.html

 Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec 
 attached to the JIRA).
 Abstract:
 This feature aims at improving the way BUILT-IN users are managed in Derby by 
 providing a more intuitive and familiar DDL interface. Currently (in 
 10.1.2.1), Built-In users can be defined at the system and/or database level. 
 Users created at the system level can be defined via JVM or/and Derby system 
 properties in the derby.properties file. Built-in users created at the 
 database level are defined via a call to a Derby system procedure 
 (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
 Defining a user at the system level is very convenient and practical during 
 the development phase (EOD) of an application - However, the user's password 
 is not encrypted and consequently appears in clear in the derby.properties 
 file. Hence, for an application going into production, whether it is embedded 
 or not, it is preferable to create users at the database level where the 
 password is encrypted.
 There is no real ANSI SQL standard for managing users in SQL but by providing 
 a more intuitive and known interface, it will ease Built-In User management 
 at the database level as well as Derby's adoption.

-- 
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

[jira] Commented: (DERBY-213) ResultSet.next() after last row of FORWARD_ONLY cursor throws an SQL Exception with Network Server

2006-01-25 Thread Knut Anders Hatlen (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-213?page=comments#action_12363960 ] 

Knut Anders Hatlen commented on DERBY-213:
--

The comments (and resolution=fixed) indicate that we should close this issue. 
Any objections?

 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 Client
 Versions: 10.1.1.0
 Reporter: Kathey Marsden
 Assignee: Philip Wilder
  Fix For: 10.2.0.0
  Attachments: Client.java, Create.java, DERBY-213_6_13_2005.txt, 
 DERBY-213_6_9_2005.txt, DERBY-213_irc_6_3_2005, DERBY-213_irc_6_7_2005.txt, 
 DERBY-213_irc_6_8_2005, Derby213patch_Aug112005.patch, 
 Derby213patch_Aug242005.patch, IRCTranscript_June2_2005.txt, ResultSet 
 Outline.pdf, 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: -9
 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

Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver

Anurag Shekhar wrote:



 I checked the classes calling using Util to get the SQLException either
 already have the reference of InternalDriver or they can be easily
 modified to have this reference. There appears to be 1 problem class
 EmbedResultSetMetaData.
 
 EmbedResultSetMetaData is being instantiated staticly from many classes
 (eg  org.apache.derby.diag.StatementDuration, StatementCache). I am not
 sure if its safe to assume that InternalDriver variable will be
 initialized before these classes are loaded.

Would it be acceptable for there to continue to be a static method in
Util that worked as it does today, always returning a
java.sql.SQLException? This method would have sanity checks to ensure
that the SQLState passed in did not start wiht any of the special values
that require specific sub-classes of SQLException. Then cases like
EmbedResultSetMetaData could use that method as the exeception it raises
does not have one of the special SQL states.

Of course this would only work until sometime in the future when
additional special codes are created, but as Tim Bray likes to say don't
over engineer now, You ain't going to need it.

Dan.

Re: conflict between Derby API and JDBC 4.0

2006-01-25 Thread Lance J. Andersen

Generics can be used on signatures for existing methods when it makes 
sense.  If you look at Java SE 5.0, you will see many methods whose 
signatures changed (Collections API is an obvious example) without 
breaking compatibility with earlier code at runtime.


-lance

Andrew McIntyre wrote:



On Jan 24, 2006, at 11:28 PM, Andrew McIntyre wrote:

and the JSR-014 charter says that JDBC 4.0 should be backwards  
compatible with JDBC 3.0



I meant JSR-221 here. A quick scan of the specs and javadoc that  
didn't require a license agreement seem to indicate that generics are  
only used on methods new to JDBC 4.0.


andrew

[jira] Created: (DERBY-872) Fix how to measure performance of lob streaming

2006-01-25 Thread Tomohito Nakayama (JIRA)

Fix how to measure performance of lob streaming
---

 Key: DERBY-872
 URL: http://issues.apache.org/jira/browse/DERBY-872
 Project: Derby
Type: Sub-task
  Components: Performance, Test  
Reporter: Tomohito Nakayama
 Assigned to: Tomohito Nakayama 


I think the measurement should be done in next 3 points of view at least.

1: Stability of performance.
See the influence of long run.

2: Performance for volume.
See the influence of size of  binary to be streamed.

3: Difference in type of LOB
See the influence of type of LOB, BLOB or CLOB.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/43D75FD0.1020603%40basil.ocn.ne.jp

-- 
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

[jira] Updated: (DERBY-872) Fix how to measure performance of lob streaming

2006-01-25 Thread Tomohito Nakayama (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-872?page=all ]

Tomohito Nakayama updated DERBY-872:


Attachment: TestDriver.java
run.ksh
file_500k.txt

I revised ClobTest program contributed by Sunitha so that we can test blob not 
only clob , which was tested originally.

 Fix how to measure performance of lob streaming
 ---

  Key: DERBY-872
  URL: http://issues.apache.org/jira/browse/DERBY-872
  Project: Derby
 Type: Sub-task
   Components: Performance, Test
 Reporter: Tomohito Nakayama
 Assignee: Tomohito Nakayama
  Attachments: TestDriver.java, file_500k.txt, run.ksh

 I think the measurement should be done in next 3 points of view at least.
 1: Stability of performance.
 See the influence of long run.
 2: Performance for volume.
 See the influence of size of  binary to be streamed.
 3: Difference in type of LOB
 See the influence of type of LOB, BLOB or CLOB.
 http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/43D75FD0.1020603%40basil.ocn.ne.jp

-- 
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

Re: conflict between Derby API and JDBC 4.0

I really really don't want to see us modifying the class to indicate a 
different class version.  This path seems fraught with peril; this type 
of white lie (actually it's a pretty big lie) seems to me fraught with 
peril; who knows what other functionality depends on correct versioning 
of the class file?


David

Andrew McIntyre wrote:


On Jan 24, 2006, at 5:13 PM, Daniel John Debrunner wrote:


Are generics represented by new entries in the class file that break on

older VMs?



This question caught my eye, and I did a little research. The answer is 
both yes and no.


The bytecode for generics is compatible with older VMs because the 
generic type signature is erased at compile time and appropriate casts 
added by the compiler. The new methods could be used in the older VM, 
but casts which were not expected when the newer class was compiled 
would result in a ClassCastException. 

But, attempting to load a class with generics compiled with 1.5/1.6 in a 
1.4 JVM yields this error:


Exception in thread main java.lang.UnsupportedClassVersionError: 
Generic (Unsupported major.minor version 49.0)


It is also not possible to compile a class with generics with -target 1.4.

But, you could change the class version so that the class got past the 
verifier on the earlier VM and it would still work. I even verified that 
this would work with a simple test case. I haven't had time to look at 
whether the new methods with generics have counterparts in JDBC 3.0, but 
assuming they don't, and the JSR-014 charter says that JDBC 4.0 should 
be backwards compatible with JDBC 3.0, altering the class version would 
do the trick.


But, then you've entered the dreaded area of modifying class files 
post-compilation. :-)


Also, I found this 
document: http://homepages.inf.ed.ac.uk/wadler/gj/Documents/gj-oopsla.pdf 
very enlightening as to the mechanics of how generic types are handled 
in the compiler. It was linked from the JSR-014 page.


andrew
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Tagline for Derby

I think we could move the tagline out of the image, at least on our home 
page.


BTW, things are looking very good for our use of the word Java as a 
modifier, including Pure Java Database or Java Open Source Database. 
  I will get you details once I have them.


David

Jean T. Anderson wrote:

Kathey Marsden wrote:


Jean T. Anderson wrote:


Francois Orsini wrote:


Right this is where I got it from - I  mentioned this as Derby is an
Apache (2.0) based project - Hence, am curious as to what the
trademark issue would be really for a tagline such Open Source
Database (the one you mentioned) - is a separate license needed or 
not?




My concern was using the words open source, but other email from Dan
indicates that this shouldn't be an issue.

But I seriously wonder if we want to have a tagline that could require
explanation -- and translation, as Dan also pointed out.



I think  no tagline would be fine.

I noticed, however, that a Google search  for open source database 
did not hit our website in at least the first 10 pages, but did see many

other open source database alternatives  there.  I am guessing that tag
line would add us to the search, but perhaps there is something else we
could do with our website to put us there.



The tagline is part of the image -- does google index images?

 -jean

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

[jira] Assigned: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen

2006-01-25 Thread Daniel John Debrunner (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-766?page=all ]

Daniel John Debrunner reassigned DERBY-766:
---

Assign To: Daniel John Debrunner

 Improve code generation to handle 5000 unions in a select the  union test  in 
 largeCodeGen
 --

  Key: DERBY-766
  URL: http://issues.apache.org/jira/browse/DERBY-766
  Project: Derby
 Type: Sub-task
   Components: Services
 Versions: 10.2.0.0
 Reporter: Kathey Marsden
 Assignee: Daniel John Debrunner
  Fix For: 10.2.0.0


 A good incremental improvement for code generation for 10.2 would be to 
 handle 5000 unions in the  largeCodeGen test.
 eg.   largeUnionSelect(con, viewName, 5000);
 should pass.

-- 
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

Re: conflict between Derby API and JDBC 4.0

David W. Van Couvering wrote:

 I really really don't want to see us modifying the class to indicate a
 different class version.  This path seems fraught with peril; this type
 of white lie (actually it's a pretty big lie) seems to me fraught with
 peril; who knows what other functionality depends on correct versioning
 of the class file?

That should be well defined by the JVM specification and updates from
Sun. Though I've never seen any definition of what the class major and
minor version imply, makes it hard to generate byte code. :-( I've
mentioned this to the J2SE spec lead before, though it was over beers.

Dan.

Re: Features of the JUnit test execution harness

I have to agree we're missing a well-defined pattern and associated 
guidebook on how to do this right.  And I agree we should get this 
done before too many more JUnit tests are written.


David

Daniel John Debrunner wrote:

Daniel John Debrunner wrote:



David W. Van Couvering wrote:




I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?



Depends, at some point you put the potential burden of fixing all those
new tests on the person doing the cleanup, that should have been part of
the original submission.



The other issue is that we have a great opportunity to start out with
JUnit tests that follow a consistent pattern and provide a great example
for others to follow. If we add a number of tests now that haphazardly
use the methods in DerbyJUnitTest (because they are not well commented)
then we have a set of tests like the current ones. No pattern, no
obvious starting point leading to people inventing their own ways to get
connections, run ddl, handle exceptions etc.

Dan.


begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12363970 ] 

Rick Hillegas commented on DERBY-856:
-

This seems straightforward and the derbyall tests pass. NSinSameVM has the same 
errors we see in the mainline. There is some instability in readlocks.sql but 
that test passed when I re-ran it.

 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

I need developer access to jira

2006-01-25 Thread Eric Radzinski

Can somebody grant me developer access to jira? There are a couple of doc issues that I need to assign to myself. My jira user ID is ericrad.Thx.
		Do you Yahoo!? 
With a free 1 GB, there's more in store with Yahoo! Mail.

Re: Features of the JUnit test execution harness

2006-01-25 Thread Rick Hillegas

I apologize for the radio silence on this topic. I have been on the road 
and unable to address these concerns. Today I will put some effort into 
beefing up the comments in DerbyJUnitTest and handling the swallowed 
exceptions.


I agree that we need a primer for writing JUnit tests. I can mock up 
such a document and we can collectively polish it. I would like to start 
out with something small. I believe that other people are working on a 
larger JUnit framework and I would like their help in building up this 
document.


Thanks for your patience,
-Rick

David W. Van Couvering wrote:

I agree with you that is disconcerting, but can't JUnit tests be 
written that extend DerbyJUnitTest in parallel with getting 
DerbyJUnitTest cleaned up to everyone's satisfaction?


BTW, if you don't like the rampant catching and ignoring, is anything 
preventing you from going in and fixing it? :)  I suppose we need to 
hear from Rick about his feelings around this before we go and reverse 
his changes...


David

Daniel John Debrunner wrote:




I would like my concerns to be cleared up before too many tests use the
current Junit facility. The rampant catching and ignoring of
SQLExceptions is not good.

Dan.

Re: [PATCH](DERBY-783) Enhance ALTER TABLE syntax to allow users to change the next value to be generated for an identity column

2006-01-25 Thread Mamta Satoor

Hi Satheesh,

I have made changes so the autoIncrementStartin SYSCOLUMNS gets set to new value provided by RESTART WITH. I have attached the patch to the JIRA entry.

svn stat
M java\engine\org\apache\derby\impl\sql\catalog\SYSCOLUMNSRowFactory.javaM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out

thanks,
Mamta
On 1/23/06, Mamta Satoor [EMAIL PROTECTED] wrote:

I can look into it to see if it would impact anything if the autoIncrementStartis changed in SYSCOLUMNS. If everything looks good, I will post a patch soon.

thanks,
Mamta

On 1/23/06, Satheesh Bandaram [EMAIL PROTECTED]
wrote:
Hi Mamta,Thanks for addressing the comments...Mamta Satoor wrote:

Hi Satheesh,

2)I didn't consider changingautoIncrementStartin SYSCOLUMNSRowFactory.java because this value doesn't get looked at when the next value isgenerated after the RESTART WITH alter table command.
Right... This start value is not used for generating the next value... but if any applications look at the START value from the catalogs for any reason, it would still show OLD start value, not the new value set by RESTART option. Do you see any problems in setting START with the new value? It is documented in the manuals, under catalogs.
Satheesh

On 1/20/06, Satheesh Bandaram [EMAIL PROTECTED]
wrote:
Hi Mamta,I think we need to mark 'RESTART' as a non-reserved word and also have couple of other comments. This can be submitted separately, so I committed the patch.
Transmitting file data ..Committed revision 370885.Here are some comments:

RESTART needs to be marked as non-reserved word. Can you add this to nonReservedKeyword() list? Currently, attempts to create a table with RESTART name fails. (considers it as reserved word)
About your change to SYSCOLUMNSRowFactory.java, should we mark autoIncrementStart with the new value?
+ {//user asked for restart with a new value, so don't change increment by and original start+ //with values in the SYSCOLUMNS table. Just record the RESTART WITH value as the
+ //next value to be generated in the SYSCOLUMNS table+ ColumnDescriptor column = (ColumnDescriptor)td;+ row.setColumn(SYSCOLUMNS_AUTOINCREMENTVALUE, new SQLLongint(autoincStart));
+ row.setColumn(SYSCOLUMNS_AUTOINCREMENTSTART, new SQLLongint(+ column.getTableDescriptor().getColumnDescriptor(colName).getAutoincStart()));
+ row.setColumn(SYSCOLUMNS_AUTOINCREMENTINC, new SQLLongint(+ column.getTableDescriptor().getColumnDescriptor(colName).getAutoincInc()));
Is there a need to prevent RESTART option under soft upgrade? I don't think so, since you are not adding any disk footprint, but just thought I will bring it up.Satheesh
Mamta Satoor wrote:

Hi Satheesh,

I have rerun the tests and didn't see any failures after doing a sync. Can you please look into commiting the new review package attached to the JIRA entry?

thanks,
Mamta
On 1/16/06, Mamta Satoor [EMAIL PROTECTED] wrote:

Hi Satheesh,

Thanks for looking into committing this patch. I have done a sync on my client and will look into resolving the conflicts. After that, Iwant to rerun all the tests before submitting an updated patch.
Mamta

On 1/16/06, Satheesh Bandaram [EMAIL PROTECTED]
wrote:
Hi Mamta,Since I applied your other patch, this patch can't be applied as is. (since they share some of the same files) Can you update your patch and post it, please?
Satheesh
Mamta Satoor wrote:

Posted this few days back. Anyone has comments?

Thanks,
Mamta
On 1/3/06, Mamta Satoor [EMAIL PROTECTED] wrote:

Hi,

I have attached a review package for this feature to the JIRA entry. Following is a brief description of the changes involved.
Changed sqlgrammar.jj to add parser support for ALTER TABLE tablename ALTER columnName RESTART WITH integer-constant
Also, added another element to the array which keeps track of autoincrement information in the parser. This 4th element will record if the autoincrement column is getting added or it is getting altered for INCREMENT BY value change or it is getting altered for
RESTART WITH value change. This information is required later in the compile and execute phase.
In the compile phase, this information is used to see if a user is trying to sneak in a value of 0 for INCREMENT BY. A value of 0 for INCREMENT BY should be caught at the time of autoincrement column add or at the time of autoincrement column
alter to change the INCREMENT BY value. At the time of autoincrement column alter to change the RESTART WITH value,the INCREMENT BY value should not be checked. This is done in
ColumnDefinitionNode.java. TableElementList generates ColumnInfo which needs to keep track of autoincrement column change status from ColumnDefinitionNode. This infromation in ColumnInfo will be used at execute time.

In the execute phase, we need to know which columns of SYSCOLUMNS table need to be changed for an ALTER TABLE command on the autoincrement column. In the past, we only allowed to change the INCREMENT BY criteria of an

[jira] Closed: (DERBY-810) intermittent diff for store/RecoveryAfterBackup.java test

 [ http://issues.apache.org/jira/browse/DERBY-810?page=all ]
 
Kathey Marsden closed DERBY-810:



 intermittent diff for store/RecoveryAfterBackup.java test
 -

  Key: DERBY-810
  URL: http://issues.apache.org/jira/browse/DERBY-810
  Project: Derby
 Type: Test
   Components: Store
 Versions: 10.2.0.0
  Environment: Sun jdk 1.5
 Reporter: Kathey Marsden
 Assignee: Øystein Grøvlen
  Fix For: 10.2.0.0
  Attachments: derby-810.diff, derby-810.stat

 I saw this diff for test running at 2006-01-11 00:45:23  PST. The test seemed 
 to run fine the next night.It would appear that this is some sort of 
 intermittent test output problem.   The test was just checked in on 
 2006-01-09.
 store/RecoveryAfterBackup.java.  on jdk15
 *** Start: RecoveryAfterBackup jdk1.5.0_02 storeall:storerecovery 2006-01-11 
 00:45:23 ***
 4 del
  SQL Exception: Derby system shutdown.
 5 del
  Starting restore with roll-forward recovery..
 5a4
  SQL Exception: Derby system shutdown.Starting restore with roll-forward 
  recovery..
 Test Failed.

-- 
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

documenting DERBY-571: virtual table mapping for no argument diagnostic tables

2006-01-25 Thread Eric Radzinski

Can somebody tell me ifthe four tables that are associated with this issue need to be documented? The tables are:SYSCS_DIAG.LOCK_TABLE SYSCS_DIAG.STATEMENT_CACHE SYSCS_DIAG.TRANSACTION_TABLE SYSCS_DIAG.ERROR_MESSAGES If so, I'll start putting together a draft.
		Do you Yahoo!? 
With a free 1 GB, there's more in store with Yahoo! Mail.

[jira] Closed: (DERBY-421) starting an XA transaction resets the isolation level set with SET CURRENT ISOLATION

 [ http://issues.apache.org/jira/browse/DERBY-421?page=all ]
 
Kathey Marsden closed DERBY-421:



 starting an XA transaction resets the isolation level set with SET CURRENT 
 ISOLATION
 

  Key: DERBY-421
  URL: http://issues.apache.org/jira/browse/DERBY-421
  Project: Derby
 Type: Sub-task
   Components: JDBC
 Reporter: Kathey Marsden
 Assignee: Mamta A. Satoor
  Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.1
  Attachments: derby421XAIsolation082205.txt, derby421XAIsolation083005.txt

 When an XA Transaction is started the isolation level set with SET CURRENT 
 ISOLATION gets reset to CS.
 Embedded setTransactionIsolation  does not have this problem but this problem 
 is the root cause of DERBY-414 because client implements 
 setTransactionIsolation by sending SET CURRENT ISOLATION
 $ java TestSetCurrentIsolation
 Database product: Apache Derby
 Database version: 10.2.0.0 alpha
 Driver name:  Apache Derby Embedded JDBC Driver
 Driver version:   10.2.0.0 alpha
 SET CURRENT ISOLATION = UR
 CURRENT ISOLATION: UR
 getTransactionIsolation:TRANSACTION_READ_UNCOMMITTED:1
 Isolation level after xa start
 CURRENT ISOLATION: CS
 getTransactionIsolation:TRANSACTION_READ_COMMITTED:2
 $
 import java.sql.*;
 import javax.sql.*;
 import javax.transaction.xa.*;
 public class TestSetCurrentIsolation
 {
 public static void main(String[] args) throws Throwable
 {
 try
 {
  final org.apache.derby.jdbc.EmbeddedXADataSource ds =
  new org.apache.derby.jdbc.EmbeddedXADataSource();
  ds.setDatabaseName(C:\\drivers\\derby\\databases\\SCHEDDB);
  ds.setUser(dbuser1);
  ds.setPassword(**);
 XAConnection xaConn = ds.getXAConnection();
 Connection conn = xaConn.getConnection();
 conn.setAutoCommit(true);
 System.out.println(Database product:  + 
 conn.getMetaData().getDatabaseProductName());
 System.out.println(Database version:  + 
 conn.getMetaData().getDatabaseProductVersion());
 System.out.println(Driver name:   + 
 conn.getMetaData().getDriverName());
 System.out.println(Driver version:+ 
 conn.getMetaData().getDriverVersion());
 Statement stmt = conn.createStatement();
 System.out.println(SET CURRENT ISOLATION = UR);
 stmt.executeUpdate(SET CURRENT ISOLATION = UR);
 showIsolationLevel(conn);
 conn.setAutoCommit(false);
 XAResource xaRes = xaConn.getXAResource();
 Xid xid = new TestXid(1,(byte) 32, (byte) 32);
 xaRes.start(xid, XAResource.TMNOFLAGS);
 System.out.println(Isolation level after xa start);
 showIsolationLevel(conn);
 
 xaRes.end(xid, XAResource.TMSUCCESS);
 xaRes.rollback(xid);
 conn.close();
 xaConn.close();
 }
 catch (SQLException sqlX)
 {
 System.out.println(Error on thread 1.);
 do sqlX.printStackTrace();
 while ((sqlX = sqlX.getNextException()) != null);
 }
 catch (Throwable th)
 {
 System.out.println(Error on thread 1.);
 do th.printStackTrace();
 while ((th = th.getCause()) != null);
 }
 }
   /**
* @param conn
* @throws SQLException
*/
   private static void showIsolationLevel(Connection conn) throws 
 SQLException {
   PreparedStatement ps = conn.prepareStatement(VALUES CURRENT 
 ISOLATION);
   ResultSet rs = ps.executeQuery();
   //ResultSet rs = conn.createStatement().executeQuery(VALUES 
 CURRENT ISOLATION);
   rs.next();
   System.out.println(CURRENT ISOLATION:  +  rs.getString(1));
   System.out.println(getTransactionIsolation: + 
   
 getIsoLevelName(conn.getTransactionIsolation())); 
   
   }
   
   public static String getIsoLevelName(int level)
   {
   switch (level) {
   case java.sql.Connection.TRANSACTION_REPEATABLE_READ:
   return TRANSACTION_REAPEATABLE_READ: + level;
   
   case java.sql.Connection.TRANSACTION_READ_COMMITTED:
   return TRANSACTION_READ_COMMITTED: + level;
   case java.sql.Connection.TRANSACTION_SERIALIZABLE:
   return TRANSACTION_SERIALIZABLE: + level;
   case java.sql.Connection.TRANSACTION_READ_UNCOMMITTED:
   return TRANSACTION_READ_UNCOMMITTED: + level;
   }
   return

Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

2006-01-25 Thread Bryan Pendleton


Mike Matrigali wrote:

2) determine if the existing lock is false, ie. the creating process
   exited without cleaning up the lock file.


Is the reason that this is hard because File.deleteOnExit() is not reliable?

thanks,

bryan

[jira] Closed: (DERBY-410) ClientDataSource should not require serverName/portNumber to be set

 [ http://issues.apache.org/jira/browse/DERBY-410?page=all ]
 
Kathey Marsden closed DERBY-410:



 ClientDataSource should not require serverName/portNumber to  be set
 

  Key: DERBY-410
  URL: http://issues.apache.org/jira/browse/DERBY-410
  Project: Derby
 Type: Bug
   Components: JDBC
 Versions: 10.1.1.0, 10.2.0.0
 Reporter: Kathey Marsden
 Assignee: Philip Wilder
  Fix For: 10.1.1.0, 10.1.2.0, 10.1.1.1


 the ClientDataSource property  serverName should default to localhost but 
 is currently  required.
 http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
 See repro for DERBY-409
 and comment out the lines
 ds.setServerName(localhost);
 ds.setPortNumber(1527);

-- 
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

[jira] Closed: (DERBY-406) Client DataSource should not require user property to be set

 [ http://issues.apache.org/jira/browse/DERBY-406?page=all ]
 
Kathey Marsden closed DERBY-406:



 Client DataSource should not require user property to be set
 

  Key: DERBY-406
  URL: http://issues.apache.org/jira/browse/DERBY-406
  Project: Derby
 Type: Bug
   Components: Network Client
 Versions: 10.1.1.0, 10.2.0.0
 Reporter: Kathey Marsden
 Assignee: Philip Wilder
  Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.1
  Attachments: DataSourceNoUser.java, Derby406_409_410.patch

 ClientDataSource should not require user to be set.  It should default to 
 user APP as described in:
 http://incubator.apache.org/derby/docs/adminguide/cadminappsclient.html
 This all seems to work ok for for DriverManager connections but fails for 
 ClientDataSource 
 run the attached repro 
 $ java DataSourceNoUser
 embedded no userid/password
 client userid/password set
 client no password
 client no userid/no password
 org.apache.derby.client.am.SqlException: null userid not supported
 at 
 org.apache.derby.client.net.NetConnection.checkUser(NetConnection.java:998)
 at 
 org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:380)
 at 
 org.apache.derby.client.net.NetConnection.initialize(NetConnection.java:233)
 at 
 org.apache.derby.client.net.NetConnection.init(NetConnection.java:201)
 at 
 org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:156)
 at 
 org.apache.derby.jdbc.ClientDataSource.getConnection(ClientDataSource.java:135)
 at DataSourceNoUser.main(DataSourceNoUser.java:42)

-- 
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

[jira] Closed: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java

 [ http://issues.apache.org/jira/browse/DERBY-214?page=all ]
 
Kathey Marsden closed DERBY-214:



 Remove System.exit() calls from the DB2jServerImpl.java
 ---

  Key: DERBY-214
  URL: http://issues.apache.org/jira/browse/DERBY-214
  Project: Derby
 Type: Bug
   Components: Network Server
 Versions: 10.1.1.0
 Reporter: Kathey Marsden
 Assignee: David Van Couvering
  Fix For: 10.1.1.0
  Attachments: DERBY-214.diff

 The System.exit() calls needs to be removed from the 
 DB2jServerImpl.java as this results in the entire application 
 (example - Eclipse which is running the Network Server inside 
 it) getting shut down.

-- 
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

[jira] Closed: (DERBY-339) Network client XA should only keep XA state for transaction branch association, to track whether to send commit in autocommit mode. All other state and state related decisi

 [ http://issues.apache.org/jira/browse/DERBY-339?page=all ]
 
Kathey Marsden closed DERBY-339:



 Network client XA should only keep XA state for transaction branch 
 association, to track whether to send commit in autocommit mode.  All other 
 state and state related decisions should be deferred to the server.
 --

  Key: DERBY-339
  URL: http://issues.apache.org/jira/browse/DERBY-339
  Project: Derby
 Type: Bug
   Components: Network Client
 Versions: 10.1.1.0
 Reporter: Kathey Marsden
 Assignee: Kathey Marsden
  Fix For: 10.1.1.0
  Attachments: derby339.diff

 Network client XA should only keep XA state for transaction branch 
 association, to track whether to send commit in autocommit mode.  All other 
 state and state related decisions should be defered to the server.
 The client tries to track XA state to make decisions based on current XA 
 state.  Most of this state handling was removed with DERBY246, but it still 
 was not being handled properly.  This is evidenced by multiple failures in 
 xaSimplePostive that now that it gets past DERBY-246.
 This fix will have the client track only branch association as outlined in 
 the XA+ specification. Table 6-2, State Table for Transaction Branch 
 Association.  The client will track only
 XA_TO_NOT_ASSOCIATED
 XA_T1_ASSOCIATED
 Association Suspended (T2) will map to XA_TO_NOT_ASSOCIATED for the client's 
 pupurposes.
 The client commit in autocommit mode only for 
 XA_TO_NOT_ASSOCIATED.

-- 
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

Changing the location of the derby log file

2006-01-25 Thread Afkham Azeez

Hi Folks,

I'm using Derby with Hibernate as the ORM. I noticed that the
derby.log file is getting created in the the directory from where I
started the application. Is there a way of specifying the location of
the log file?

--
Thanks
Afkham Azeez

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

2006-01-25 Thread Deepa Remesh (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12363983 ] 

Deepa Remesh commented on DERBY-210:


Thanks Kathey, Bryan and Dan for your comments. 

As Bryan pointed out, the javadoc for Statement.close mentions A Statement 
object is automatically closed when it is garbage collected. I did not see 
this mentioned in the JDBC spec though. However, I still think close() and 
finalize() must be different. close() methods can throw SQLExceptions. javadoc 
for finalize() says this Any exception thrown by the finalize method causes 
the finalization of this object to be halted, but is otherwise ignored. So I 
think we should just ensure that we can clean up all resources when finalize() 
gets run.  Another reason which Dan pointed out is that  the order of finalizer 
execution is not guaranteed.

Dan, after reading through Section 10.1, I think we do not need to auto-commit 
when we close a statement.

Kathey, I tried to force gc to repro this problem on other VMs. But I was not 
successful in creating another repro. The thing is that I am not able to repro 
this at all anymore, not even on jdk1.5. After I updated my local svn workspace 
and applied my original patch, I do not get this problem anymore. However, it 
consistently repoduces with jdk1.5 when running with the revision where the 
patch was committed (svn 369612). So I am doing changes on svn revision 369612 
and running tests to verify this problem does not occur. Then I'll update to 
latest svn revision, do the same changes and run tests. I cannot think of any 
other way to verify this.

 Network Server will leak prepared statements if not explicitly closed by the 
 user until the connection is closed
 

  Key: DERBY-210
  URL: http://issues.apache.org/jira/browse/DERBY-210
  Project: Derby
 Type: Bug
   Components: Network Client
 Reporter: Kathey Marsden
 Assignee: Deepa Remesh
  Attachments: derby-210.diff, derby-210.status, derbyStress.java

 Network server will not garbage collect prepared statements that are not 
 explicitly closed by the user.  So  a loop like this will leak.
 ...
 PreparedStatement ps;
  for (int i = 0 ; i   numPs; i++)
   {
ps = conn.prepareStatement(selTabSql);
rs =ps.executeQuery();
while (rs.next())
   {
   rs.getString(1);
   }
   rs.close();
   // I'm a sloppy java programmer
   //ps.close();
   }
   
 To reproduce run the attached program 
 java derbyStress
 Both client and server will grow until the connection is closed.
  
 It is likely that the fix for this will have to be in the client.  The client 
 does not send protocol to close the prepared statement, but rather reuses the 
 PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been 
 closed. This is how the server knows to close the old statement and create a 
 new one.

-- 
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

Re: [jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

2006-01-25 Thread Army


Knut Anders Hatlen wrote:

Bryan Pendleton updated DERBY-491:
--

   Attachment: svn_jan_24_2006.diff


[ snip ]



I read through your patch, ran derbynetclientmats and derbynetmats
successfully, and verified that the test case failed without your
patch (actually, it didn't fail, it just hung until I got bored and
killed the test).


I too looked at the changes and they seem correct and well-documented.  I also 
ran the new tests with and without the patch applied: with the patch, they 
passed, without, the tests hung, so that's good.


My one nit-pick, though, is that it looks _both_ test cases result in a hang if 
the patch hasn't been applied.  That in itself isn't a bad thing, but based on 
the comments in the test and the error description for DERBY-491, I was 
expecting to see a protocol exception for the first test case (DERBY-491), not a 
 hang.


My guess is that the fix for DERBY-125 and/or DERBY-170 have changed the 
symptoms of DERBY-491 from protocol exception to hang--and if that's the 
case, I have no complaints with the tests per se.  I do, however, think it's 
slightly non-intuitive to have comments in the test saying that the regression 
would be a protocol exception, when in fact, given the current state of the 
codeline, the regression would actually be a hang.


Of course, I'll admit that I'm perhaps being too picky.  You've identified the 
problem, written a fix, documented it very well, and have written test cases 
that fail without your fix and pass with it--so as far as all of that goes, I 
vote a definite +1 for commit.


That said, if you wouldn't mind updating the comments in the test and/or the 
Jira entry to match the current 491 regression behavior (or perhaps to mention 
that the regression for DERBY-491 could be _either_ a protocol exception or a 
hang, depending on the situation), I think that'd be useful.  Not obligatory, 
but useful...


Thanks for your patience with my picking,
Army

Re: Features of the JUnit test execution harness

2006-01-25 Thread Kathey Marsden

Daniel John Debrunner wrote:

Daniel John Debrunner wrote:

  

David W. Van Couvering wrote:




I agree with you that is disconcerting, but can't JUnit tests be written
that extend DerbyJUnitTest in parallel with getting DerbyJUnitTest
cleaned up to everyone's satisfaction?
  

Depends, at some point you put the potential burden of fixing all those
new tests on the person doing the cleanup, that should have been part of
the original submission.



The other issue is that we have a great opportunity to start out with
JUnit tests that follow a consistent pattern and provide a great example
for others to follow. If we add a number of tests now that haphazardly
use the methods in DerbyJUnitTest (because they are not well commented)
then we have a set of tests like the current ones. No pattern, no
obvious starting point leading to people inventing their own ways to get
connections, run ddl, handle exceptions etc.

  

One thing that would be great is if there was a well defined  way to
have tests handle jvm specific, framework specific or version specific
logic, since there will have to be some replacement for the many
properties in the test harness and the individual test checks for
framework that we have now.

I suggested something like this for the client/server compatibility
testing, but did not consider JUnit.  It would be good to have something
laid out for JUnit testing so that tests are checking whether
functionality is suppported and the details of whether that is because
of the framework, jvm or whatever are not spread around all the tests.

http://www.nabble.com/Server-and-client-compatibility-test-for-10.2-and-10.1-t913020.html#a2499854

Kathey

Re: [jira] Updated: (DERBY-491) Protocol exception when Network Server tries to return ~32K of data or greater in a result set for a Java stored procedure.

2006-01-25 Thread Bryan Pendleton

for DERBY-491, I was expecting to see a protocol exception for the first 
test case (DERBY-491), not a  hang.


Interesting. That's my expectation too, so I'm not sure I understand
why the behavior changed.

Good catch! Let me investigate this and see if I can learn more about
what this new behavior is.

thanks,

bryan

Re: Changing the location of the derby log file

2006-01-25 Thread Manjula G Kutty


Afkham Azeez wrote:


Hi Folks,

I'm using Derby with Hibernate as the ORM. I noticed that the
derby.log file is getting created in the the directory from where I
started the application. Is there a way of specifying the location of
the log file?

--
Thanks
Afkham Azeez

 


You can specify the log file in the derby.properties file.
example : derby.stream.error.file=c:/log/derby.log

http://db.apache.org/derby/docs/10.1/tuning/

Thanks
Manjula

Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux


yes, I believe it does not work if you kill the JVM.  I think it also
did not work if you call System.exit(), but I am don't remember that
exactly.  At least that use to be the case.

Bryan Pendleton wrote:

Mike Matrigali wrote:


2) determine if the existing lock is false, ie. the creating process
   exited without cleaning up the lock file.



Is the reason that this is hard because File.deleteOnExit() is not 
reliable?


thanks,

bryan

Re: [jira] Updated: (DERBY-665) Remove backup(File ...) methods


I have committed this patch.  Derbyall ran clean on XP and sun jdk1.4.2.

Mike Matrigali wrote:

I am looking at committing this patch.

Suresh Thalamati (JIRA) wrote:



[ http://issues.apache.org/jira/browse/DERBY-665?page=all ]

Suresh Thalamati updated DERBY-665:
---

   Attachment: derby665.diff

This patch removes  the unused bacpup  functions with File  as paramteter, 
TESTS : derbyall test suite passed on Windows XP/JDK142


It would be great if some can review and commit this patch. 



svn stat:
M  java\engine\org\apache\derby\impl\db\BasicDatabase.java
M  java\engine\org\apache\derby\impl\store\access\RAMAccessManager.java
M  java\engine\org\apache\derby\impl\store\raw\RawStore.java
M  java\engine\org\apache\derby\iapi\store\access\AccessFactory.java
M  java\engine\org\apache\derby\iapi\store\raw\RawStoreFactory.java
M  java\engine\org\apache\derby\database\Database.java





Remove backup(File ...) methods
---

   Key: DERBY-665
   URL: http://issues.apache.org/jira/browse/DERBY-665
   Project: Derby
  Type: Improvement
Components: Store
  Versions: 10.2.0.0
Environment: Any
  Reporter: Øystein Grøvlen
  Assignee: Suresh Thalamati
  Priority: Minor
Attachments: derby665.diff

The code contains backup methods both for specifying the backup directory both 
as a String and as a File parameter.  Only the String versions are currently 
used.  The File versions should be removed to avoid duplication of code etc.
Examples of such methods are:
BasicDatabase.backup
BasicDatabase.backupAndEnableLogArchiveMode
RAMAccessManager.backup
RAMAccessManager.backupAndEnableLogArchiveMode
RawStore.backupAndEnableLogArchiveMode
plus corresponding interfaces.

Re: Tagline for Derby

no tag line would be fine with me.  If we use the java tagline the 
lawyers must make sure that once we use it there is no way in the future 
that it's use could be limited.


David W. Van Couvering wrote:
I think we could move the tagline out of the image, at least on our home 
page.


BTW, things are looking very good for our use of the word Java as a 
modifier, including Pure Java Database or Java Open Source Database. 
  I will get you details once I have them.


David

Jean T. Anderson wrote:


Kathey Marsden wrote:


Jean T. Anderson wrote:


Francois Orsini wrote:


Right this is where I got it from - I  mentioned this as Derby is an
Apache (2.0) based project - Hence, am curious as to what the
trademark issue would be really for a tagline such Open Source
Database (the one you mentioned) - is a separate license needed or 
not?





My concern was using the words open source, but other email from Dan
indicates that this shouldn't be an issue.

But I seriously wonder if we want to have a tagline that could require
explanation -- and translation, as Dan also pointed out.



I think  no tagline would be fine.

I noticed, however, that a Google search  for open source database 
did not hit our website in at least the first 10 pages, but did see many

other open source database alternatives  there.  I am guessing that tag
line would add us to the search, but perhaps there is something else we
could do with our website to put us there.




The tagline is part of the image -- does google index images?

 -jean

Re: I need developer access to jira

2006-01-25 Thread Satheesh Bandaram





JIRA is acting up right now, so I am unable to grant you this access...
Once I can access JIRA, I will add you to the developer list.

Satheesh

Eric Radzinski wrote:

  Can somebody grant me developer access to jira?
There are a couple of doc issues that I need to assign to myself. My
jira user ID is ericrad.
  
  Thx.
   
  Do you Yahoo!?
With a free 1 GB, there's more in store with Yahoo!
Mail.

Re: [jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

I going to try and take a look at the readlocks issue, but it never 
reproduces for me.  Could you post the kind of environment (# 
processors, jvm, OS) you were
running when you saw the problem and the diff to the JIRA entry 
DERBY-861, i would like to know if all intermittent failures are in

the same place in the test.:



Rick Hillegas (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12363970 ] 


Rick Hillegas commented on DERBY-856:
-

This seems straightforward and the derbyall tests pass. NSinSameVM has the same 
errors we see in the mainline. There is some instability in readlocks.sql but 
that test passed when I re-ran it.



modify setCharacterStreamInternal to take a long for the length, and perform the 
 max int check in the method
--

Key: DERBY-856
URL: http://issues.apache.org/jira/browse/DERBY-856
Project: Derby
   Type: Improvement
 Components: JDBC
   Versions: 10.2.0.0
Environment: All Environments
   Reporter: V.Narayanan
   Assignee: V.Narayanan
   Priority: Minor
Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat

A similar change to setBinaryStreamInternal is being handled as part of DERBY-599.

Re: I need developer access to jira



On Jan 25, 2006, at 8:23 AM, Eric Radzinski wrote:

Can somebody grant me developer access to jira?  There are a couple  
of doc issues that I need to assign to myself.  My jira user ID is  
ericrad.


Hi Eric,

I've granted you access, but your email address in JIRA is listed as  
[EMAIL PROTECTED], whereas your email address on derby-dev is  
[EMAIL PROTECTED] Your JIRA emails may be going to a different  
person, unless both addresses are yours. :-)


andrew

Re: [jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

2006-01-25 Thread Rick Hillegas


Thanks, Mike. I have clipped this info to DERBY-861.

Regards,
-Rick

Mike Matrigali wrote:

I going to try and take a look at the readlocks issue, but it never 
reproduces for me.  Could you post the kind of environment (# 
processors, jvm, OS) you were
running when you saw the problem and the diff to the JIRA entry 
DERBY-861, i would like to know if all intermittent failures are in

the same place in the test.:



Rick Hillegas (JIRA) wrote:

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12363970 
]

Rick Hillegas commented on DERBY-856:
-

This seems straightforward and the derbyall tests pass. NSinSameVM 
has the same errors we see in the mainline. There is some instability 
in readlocks.sql but that test passed when I re-ran it.



modify setCharacterStreamInternal to take a long for the length, and 
perform the  max int check in the method
-- 



Key: DERBY-856
URL: http://issues.apache.org/jira/browse/DERBY-856
Project: Derby
   Type: Improvement
 Components: JDBC
   Versions: 10.2.0.0
Environment: All Environments
   Reporter: V.Narayanan
   Assignee: V.Narayanan
   Priority: Minor
Attachments: setCharacterStreamInternal.diff, 
setCharacterStreamInternal.stat


A similar change to setBinaryStreamInternal is being handled as part 
of DERBY-599.

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12363989 ] 

Rick Hillegas commented on DERBY-856:
-

Hi Mike,

Thanks for looking into the readlocks.sql failure. I ran the test under cygwin 
on XP (Version 2002, service pack 2). The machine is a 1 processor Toshiba 
Tecra 2. Here is the failure from the original testr un:

*** Start: readlocks jdk1.4.2_08 storeall:storemore 2006-01-24 16:12:13 ***
19533a19534
 APP |UserTran|ROW |1   |S   |A   |(4,6) |GRANT|ACTIVE  
Test Failed.
*** End:   readlocks jdk1.4.2_08 storeall:storemore 2006-01-24 16:14:00 ***


 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver


Looks like we already have some problem.
org.apache.derby.iapi.sql.conn.ConnectionUtil.getCurrentLCC throws 
SQLException
with status set as SQLState.NO_CURRENT_CONNECTION (0803). It doesn't use 
Util and constructs the SQLException directly.
Changing this to use Util is the easy part but this state requires us to 
throw SQLNonTransientConnectionException.


I am searching rest of the code to find if there is any other class 
which throw SQLException directly.
In my view if there are too many such instances its going to be much 
simpler and cleaner solution to have a
static methods in a class not associated with any instance to convert 
the exceptions to subtypes.


anurag

Re: Tagline for Derby


Yes, I agree

David

Mike Matrigali wrote:
no tag line would be fine with me.  If we use the java tagline the 
lawyers must make sure that once we use it there is no way in the future 
that it's use could be limited.


David W. Van Couvering wrote:

I think we could move the tagline out of the image, at least on our 
home page.


BTW, things are looking very good for our use of the word Java as a 
modifier, including Pure Java Database or Java Open Source 
Database.   I will get you details once I have them.


David

Jean T. Anderson wrote:


Kathey Marsden wrote:


Jean T. Anderson wrote:


Francois Orsini wrote:


Right this is where I got it from - I  mentioned this as Derby is an
Apache (2.0) based project - Hence, am curious as to what the
trademark issue would be really for a tagline such Open Source
Database (the one you mentioned) - is a separate license needed 
or not?






My concern was using the words open source, but other email from Dan
indicates that this shouldn't be an issue.

But I seriously wonder if we want to have a tagline that could require
explanation -- and translation, as Dan also pointed out.



I think  no tagline would be fine.

I noticed, however, that a Google search  for open source database 
did not hit our website in at least the first 10 pages, but did see 
many

other open source database alternatives  there.  I am guessing that tag
line would add us to the search, but perhaps there is something else we
could do with our website to put us there.





The tagline is part of the image -- does google index images?

 -jean



begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

[jira] Assigned: (DERBY-869) documentation to address Derby-783

2006-01-25 Thread Eric Radzinski (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-869?page=all ]

Eric Radzinski reassigned DERBY-869:


Assign To: Eric Radzinski

 documentation to address Derby-783
 --

  Key: DERBY-869
  URL: http://issues.apache.org/jira/browse/DERBY-869
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.0.2.0
 Reporter: Eric Radzinski
 Assignee: Eric Radzinski
  Attachments: derby869.diff, rrefsqlj81859.html

 document changes to ALTER TABLE syntax to address Derby-783

-- 
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

Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties shared/org/apache/derby/shared/common/reference/SQLState.java

[EMAIL PROTECTED] wrote:

 Author: davidvc
 Date: Wed Jan 25 07:25:08 2006
 New Revision: 372240
 
 URL: http://svn.apache.org/viewcvs?rev=372240view=rev
 Log:
 DERBY-400: Fixed the SQLState for some of the new client messages
 to better match what is required by SQL2003

 +# 0A - Feature not supported
 +0A002.S=jdbc 2 method is not yet implemented.
 +0A003.S=JDBC 3 method called - not yet supported

0A003 is not valid SQLstate. You need to use 0A000 or some other 0Axxx
value where the xxx is not in the range reserved by the standard (as
003) is.

I actually don't see a need for multiple error messages in this case.
Does any caller really care that it's a JDBC 2 vs. JBDC 3 method.

Dan.

Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties shared/org/apache/derby/shared/common/reference/SQLState.java

I got confused by your statement because I didn't see 0A003 in the 
table, but then I found this statement further up.  I'm quoting it here 
so that all of us working on SQL States are aware of the restriction.  A 
SQLState class is the first two characters of the state string.  A 
SQLState subclass are the last three characters of the state string.


quote
Class values that begin with one of the digits '0', '1', '2', '3', or 
'4' or one of the simple Latin upper case letters
'A', 'B', 'C', 'D', 'E', 'F', 'G', or 'H' are returned only for 
conditions defined in ISO/IEC 9075 or in any other
International Standard. The range of such class values are called 
standard-defined classes. Some such class
codes are reserved for use by specific International Standards, as 
specified elsewhere in this Clause. Subclass
values associated with such classes that also begin with one of those 13 
characters are returned only for conditions
defined in ISO/IEC 9075 or some other International Standard. The range 
of such class values are called standard defined
classes. Subclass values associated with such classes that begin with 
one of the digits '5', '6', '7', '8',
or '9' or one of the simple Latin upper case letters 'I', 'J', 'K', 
'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
'X', 'Y', or 'Z' are reserved for implementation-specified conditions 
and are called implementation-defined subclasses.

/quote

In terms of having separate messages for JDBC2 and JDBC3, I was doing a 
cut-and-paste.  I could change this, I don't have any strong opinions 
about it, but it may very well create a lot of test diffs.  It's 
personally not an itch I'm motivated to scratch.


David

Daniel John Debrunner wrote:

[EMAIL PROTECTED] wrote:



Author: davidvc
Date: Wed Jan 25 07:25:08 2006
New Revision: 372240

URL: http://svn.apache.org/viewcvs?rev=372240view=rev
Log:
DERBY-400: Fixed the SQLState for some of the new client messages
to better match what is required by SQL2003




+# 0A - Feature not supported
+0A002.S=jdbc 2 method is not yet implemented.
+0A003.S=JDBC 3 method called - not yet supported



0A003 is not valid SQLstate. You need to use 0A000 or some other 0Axxx
value where the xxx is not in the range reserved by the standard (as
003) is.

I actually don't see a need for multiple error messages in this case.
Does any caller really care that it's a JDBC 2 vs. JBDC 3 method.

Dan.

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties shared/org/apache/derby/shared/common/reference/SQLState.java

David W. Van Couvering wrote:

 I got confused by your statement because I didn't see 0A003 in the
 table, but then I found this statement further up.  I'm quoting it here
 so that all of us working on SQL States are aware of the restriction.  A
 SQLState class is the first two characters of the state string.  A
 SQLState subclass are the last three characters of the state string.
 
 quote
 Class values that begin with one of the digits '0', '1', '2', '3', or
 '4' or one of the simple Latin upper case letters
 'A', 'B', 'C', 'D', 'E', 'F', 'G', or 'H' are returned only for
 conditions defined in ISO/IEC 9075 or in any other
 International Standard. The range of such class values are called
 standard-defined classes. Some such class
 codes are reserved for use by specific International Standards, as
 specified elsewhere in this Clause. Subclass
 values associated with such classes that also begin with one of those 13
 characters are returned only for conditions
 defined in ISO/IEC 9075 or some other International Standard. The range
 of such class values are called standard defined
 classes. Subclass values associated with such classes that begin with
 one of the digits '5', '6', '7', '8',
 or '9' or one of the simple Latin upper case letters 'I', 'J', 'K',
 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W',
 'X', 'Y', or 'Z' are reserved for implementation-specified conditions
 and are called implementation-defined subclasses.
 /quote
 
 In terms of having separate messages for JDBC2 and JDBC3, I was doing a
 cut-and-paste.  I could change this, I don't have any strong opinions
 about it, but it may very well create a lot of test diffs.  It's
 personally not an itch I'm motivated to scratch.

Since the diffs will occur anyway when you change the SQLState, it could
be combined. Changing the SQLState to be valid does seem to be the itch
your are scratching, given the description of DERBY-400.

Dan.

Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of database from different classloaders on Linux

2006-01-25 Thread Suresh Thalamati

In addition to that, there is also a jvm bug related to this call, 
which can lead to memory leaks. 
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4513817


I had too much fun tracking that leak a while ago.

-suresh

Mike Matrigali wrote:

yes, I believe it does not work if you kill the JVM.  I think it also
did not work if you call System.exit(), but I am don't remember that
exactly.  At least that use to be the case.

Bryan Pendleton wrote:


Mike Matrigali wrote:


2) determine if the existing lock is false, ie. the creating process
   exited without cleaning up the lock file.




Is the reason that this is hard because File.deleteOnExit() is not 
reliable?


thanks,

bryan

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

[ 
http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12363995 ] 

Kathey Marsden commented on DERBY-210:
--

I agree  that garbage collection should not drive a commit, for the reasons 
stated by you and Dan and the fact that it is just to scary.  It would mean 
non-holdable cursors will close, some transaction in progress can just commit 
out of the blue, etc, so it sounds like not a good thing to me.

In terms of a repro, I would think you could repro the gc commit  with your fix 
by 
1) make sure autocommit is on
2) Execute a select with a holdable cursor and do not select the last row.  
3) set the Statement reference to null.
4) Execute a select with a non-holdable cursor.  Do not fetch the last row.
5) force gc.
6) Try to select the next row for the non-holdable cursor.  It should say the 
cursor is closed because the gc would 


On whether a Statement.close() should drive a commit ..
From what was described earlier,  the commit comes from the ResultSet 
associated with the statement getting closed, not the statement itself.
I am loathe to enter this conversation again, as the problem seems intractable 
so will offer only quotes for evaluation by the reader.  

From section 10.1

For Select statements, the statement is complete when the associated result set 
is closed. The result set is closed as soon as one of the following occurs:
 - all of the rows have been retrieved
 - the associated Statement object is re-executed
 - another Statement object is executed on the same connection

The javadoc for Statement.close()

From Statement javadoc
When a Statement object is closed, its current ResultSet object, if one exists, 
is also closed.

The javadoc for ResultSet.close() 
A ResultSet object is automatically closed by the Statement object that 
generated it when that Statement object is closed, re-executed, or is used to 
retrieve the next result from a sequence of multiple results. A ResultSet 
object is also automatically closed when it is garbage collected.



 Network Server will leak prepared statements if not explicitly closed by the 
 user until the connection is closed
 

  Key: DERBY-210
  URL: http://issues.apache.org/jira/browse/DERBY-210
  Project: Derby
 Type: Bug
   Components: Network Client
 Reporter: Kathey Marsden
 Assignee: Deepa Remesh
  Attachments: derby-210.diff, derby-210.status, derbyStress.java

 Network server will not garbage collect prepared statements that are not 
 explicitly closed by the user.  So  a loop like this will leak.
 ...
 PreparedStatement ps;
  for (int i = 0 ; i   numPs; i++)
   {
ps = conn.prepareStatement(selTabSql);
rs =ps.executeQuery();
while (rs.next())
   {
   rs.getString(1);
   }
   rs.close();
   // I'm a sloppy java programmer
   //ps.close();
   }
   
 To reproduce run the attached program 
 java derbyStress
 Both client and server will grow until the connection is closed.
  
 It is likely that the fix for this will have to be in the client.  The client 
 does not send protocol to close the prepared statement, but rather reuses the 
 PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been 
 closed. This is how the server knows to close the old statement and create a 
 new one.

-- 
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

Re: svn commit: r372240 - in /db/derby/code/trunk/java: client/org/apache/derby/loc/clientmessages_en.properties shared/org/apache/derby/shared/common/reference/SQLState.java

Well, a lot of messages seem to print out the message but not the SQL 
state.  I'll make the change and see how bad the diffs are.  If they're 
massive I may be motivated to switch it back to how it was.  But I'll 
give it a go.


David

Daniel John Debrunner wrote:



Since the diffs will occur anyway when you change the SQLState, it could
be combined. Changing the SQLState to be valid does seem to be the itch
your are scratching, given the description of DERBY-400.

Dan.

begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Question about derby.stream.error.file

2006-01-25 Thread Manjula G Kutty


Hi,

I came across this issue/enhancement while answering the question about 
Creating the location of the derby.log file. There is a  property 
called  'derby.stream.error.file=filename' which can be set in the 
derby.properties. After setting this up everything for the derby.log 
including the message about starting the db and shutting down goes to 
the filename given. So now my concern is doesn't that property name is 
misleading?? Can we change it from 'derby.stream.error.file' to some 
other name? may be 'derby.stream.log.file'?


Thanks,
Manjula

[jira] Commented: (DERBY-680) In ij, executing a prepared statement with numeric/decimal parameter fails with NullPointerException in J2ME/CDC/FP

[ 
http://issues.apache.org/jira/browse/DERBY-680?page=comments#action_12364002 ] 

Kathey Marsden commented on DERBY-680:
--

I think we should have a regression test that verifies the fix submitted with 
the fix, , either by enabling cast.sql with J2ME  or adding the case to another 
test that already runs with J2ME


 In ij, executing a prepared statement with numeric/decimal parameter fails 
 with NullPointerException in J2ME/CDC/FP
 ---

  Key: DERBY-680
  URL: http://issues.apache.org/jira/browse/DERBY-680
  Project: Derby
 Type: Bug
   Components: Tools
 Versions: 10.2.0.0
  Environment: j9_foundation VM in IBM WCTME 5.7
 Reporter: Deepa Remesh
 Assignee: Deepa Remesh
  Attachments: derby-680_v2.diff, derby-680_v2.status

 NPE is thrown in ij when executing prepared statement which 
 - has numeric/decimal parameters
 - does not return any result set
 Repro for this problem is the test lang/cast.sql. This test currently fails 
 in CDC/FP.
 The following lines in the test throw NPE:
 execute q10 using 'values 123456.78';
 execute q11 using 'values 123456.78';
 where q10 is prepare q10 as 'insert into t1 (num) values cast(? as 
 numeric(18))';
 and q11 is prepare q11 as 'insert into t1 (dc) values cast(? as 
 decimal(18))';
 The stack trace for failure is:
 java.lang.NullPointerException
 at org.apache.derby.impl.tools.ij.util.DisplayMulti(util.java:666)
 at 
 org.apache.derby.impl.tools.ij.utilMain.displayResult(utilMain.java:398)
 at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:290)
 at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
 at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
 at org.apache.derby.impl.tools.ij.Main.main(Main.java:75)
 at org.apache.derby.tools.ij.main(ij.java:56)
 This happens in the following code. Since the above prepared statements do 
 not return result sets, call to getMetaData() will return null. But in the 
 code, no check is done to see if getMetaData() returns null before calling 
 getColumnType.
 ---
   // In J2ME there is no object 
 that represents
   // a DECIMAL value. By default 
 use String to
   // pass values around, but for 
 integral types
   // first convert to a integral 
 type from the DECIMAL
   // because strings like 3.4 are 
 not convertible to
   // an integral type.
   switch 
 (ps.getMetaData().getColumnType(c))
   {
   case Types.BIGINT:
   ps.setLong(c, 
 rs.getLong(c));
   break;
   case Types.INTEGER:
   case Types.SMALLINT:
   case Types.TINYINT:
   ps.setInt(c, 
 rs.getInt(c));
   break;
   default:
   
 ps.setString(c,rs.getString(c));
   break;
   }   
 ---

-- 
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

[jira] Updated: (DERBY-747) Derby Logo Work

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Attachment: (was: derby-logo-web-150x90.png)

 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-20dec05-3.png, web-preview-20dec05-4.png, 
 web-preview-20dec05.png, web-preview-21dec05-5.png, web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

[jira] Updated: (DERBY-747) Derby Logo Work

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Attachment: (was: web-preview-21dec05-5.png)

 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

[jira] Updated: (DERBY-747) Derby Logo Work

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Attachment: (was: web-preview-20dec05.png)

 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

[jira] Updated: (DERBY-747) Derby Logo Work

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Attachment: (was: web-preview-20dec05-4.png)

 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

[jira] Updated: (DERBY-747) Derby Logo Work

 [ http://issues.apache.org/jira/browse/DERBY-747?page=all ]

Jean T. Anderson updated DERBY-747:
---

Attachment: (was: web-preview-20dec05-3.png)

 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

Re: Tagline for Derby

2006-01-25 Thread Jean T. Anderson


David W. Van Couvering wrote:

Yes, I agree


My read is 5 Derby committers have said it's fine to drop the tagline:

 Dan Debrunner
 Kathey Marsden
 Mike Matrigali
 Jean Anderson
 David Van Couvering

If I misunderstood anyone, please let me know.

I'll post to the derby-user thread that after a derby-dev discussion we 
decided that no tagline is best.  Perhaps a variant could be added later 
that includes a tagline.


 -jean



David

Mike Matrigali wrote:

no tag line would be fine with me.  If we use the java tagline the 
lawyers must make sure that once we use it there is no way in the 
future that it's use could be limited.


David W. Van Couvering wrote:

I think we could move the tagline out of the image, at least on our 
home page.


BTW, things are looking very good for our use of the word Java as a 
modifier, including Pure Java Database or Java Open Source 
Database.   I will get you details once I have them.


David

Jean T. Anderson wrote:


Kathey Marsden wrote:


Jean T. Anderson wrote:


Francois Orsini wrote:


Right this is where I got it from - I  mentioned this as Derby is an
Apache (2.0) based project - Hence, am curious as to what the
trademark issue would be really for a tagline such Open Source
Database (the one you mentioned) - is a separate license needed 
or not?







My concern was using the words open source, but other email from 
Dan

indicates that this shouldn't be an issue.

But I seriously wonder if we want to have a tagline that could 
require

explanation -- and translation, as Dan also pointed out.



I think  no tagline would be fine.

I noticed, however, that a Google search  for open source 
database did not hit our website in at least the first 10 pages, 
but did see many
other open source database alternatives  there.  I am guessing that 
tag
line would add us to the search, but perhaps there is something 
else we

could do with our website to put us there.






The tagline is part of the image -- does google index images?

 -jean

Re: Code coverage results for trunk svn 366406

2006-01-25 Thread Ramandeep Kaur

Hi Dan,

Thanks for your question. 
Is it possible to combine multiple test coverage runs?
Yes, it is possible to runcode coverageformultiple jvms and then combine all test coverage runs.

j2me/cdc/foundationjdk13jdk14jdk15
I will run code coverage with the above jvms and will post the results as soon as they are done.
Thanks,
Ramandeep Kaur ([EMAIL PROTECTED])


On 1/17/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:
Ramandeep Kaur wrote: These are the results for a single derbyall run and for jvm - sun jdk142
Is it possible to combine multiple test coverage runs? If we hadderbyall runs for all these environments combined then the coveragewould correctly reflect the complete set of testing run.j2me/cdc/foundation
jdk13jdk14jdk15Thanks,Dan.

[jira] Commented: (DERBY-747) Derby Logo Work

[ 
http://issues.apache.org/jira/browse/DERBY-747?page=comments#action_12364006 ] 

Jean T. Anderson commented on DERBY-747:


Note: to declutter this issue I removed early attachments I submitted that were 
clearly superceded by better ideas.
I removed the following attachments:
derby-logo-web-150x90.png
web-preview-20dec05.png
web-preview-20dec05-3.png
web-preview-20dec05-4.png
web-preview-21dec05-5.png



 Derby Logo Work
 ---

  Key: DERBY-747
  URL: http://issues.apache.org/jira/browse/DERBY-747
  Project: Derby
 Type: New Feature
   Components: Documentation
 Reporter: Jean T. Anderson
 Priority: Minor
  Attachments: derby-logo-move.jpg, derby-logo-right-align.jpg, 
 derby_logo_small_dec21.png, derbylogo.ai, logo_320x200.png, logo_320x200.psd, 
 masthead_derby.png, masthead_derby2.png, masthead_derby3.png, 
 masthead_derby4.png, masthead_derby5.png, small_button_80x15_blackwhite.psd, 
 small_button_80x15_blue.psd, small_button_80x15_gold.psd, 
 small_button_80x15_orange.psd, use_of_logo.psd, web-preview-20dec05-2.png, 
 web-preview-21dec05-6.png

 The Derby logo was voted on and a logo selected; see DERBY-297. This Jira 
 issue provides a spot for uploading images for final fine tuning.

-- 
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

Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue

2006-01-25 Thread Raymond Raymond


Mike, last time you gave me some comments about how to map the
recovery time into Xmb of log. I still have some question about it.


RR2. During initilization of Derby, we run some measurement that
RR   determines the performance of the system and maps the
RR   recovery time into some X megabytes of log.


RR  Now, I am going to design the 2nd step first to map the recovery
RR  time into some
RR  X megabytes of log. A simple approach is that we can design a test
RR  log file. In the
RR  log file, we can let derby create a temporary database and do a
RR  bunch of test to get
RR  necessary disk IO information, and then delete the temporary
RR  database. When derby
RR  boots up, we let it to do recovery from the test log file.Anyone
RR  has some other
RR  suggestions on it?
MM  I'll think about this, it is not straight forward.  My guess would
MM  be that recovery time is dominated by 2 factors:
MM  1) I/O from log disk
MM  2) I/O from data disk
MM
MM  Item 1 is pretty easy to get a handle on.  During redo it is pretty
MM  much
MM  a straight scan from beginning to end doing page based I/O.  Undo is
MM  harder as it jumps back and forth for each xact.  I would probably
MM  just
MM  ignore it for estimates.
MM
MM  Item 2 is totally dependent on cache rate hit you are going to
MM  expect, and the number of log records.
MM  The majority of log records deal with a single page, it will read
MM  the page into cache if it doesn't exist and then it will do a quick
MM  operation on that page.  Again undo is slightly more complicated as
MM  it
MM  could involve logical lookups in the index.
MM
MM  Another option rather than do any sort of testing is to come up with
MM  an
MM  initial default time based on size of log file.  And then on each
MM  subsequent recovery event dynamically change the estimate based on
MM  how
MM  long that recovery on that db took.  This way each estimate will be
MM  based on the actual work generated by the application, and over time
MM  should become better and better.

I agree with you it is better to estimate with actual work generated by
the appplication. But, as I know, derby only performs recovery when it
boots(am I right here?). If Derby runs stably, the subsequent recovery
event you mentioned will not happen and we can't get the information we
need.


RR
RR  Raymond

_
Take advantage of powerful junk e-mail filters built on patented Microsoft® 
SmartScreen Technology. 
http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines 
 Start enjoying all the benefits of MSN® Premium right now and get the 
first two months FREE*.

Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver




Would it be acceptable for there to continue to be a static method in
Util that worked as it does today, always returning a
java.sql.SQLException? This method would have sanity checks to ensure
that the SQLState passed in did not start wiht any of the special values
that require specific sub-classes of SQLException. Then cases like
EmbedResultSetMetaData could use that method as the exeception it raises
does not have one of the special SQL states.


 

I have looked into the code base there are several places where 
SQLException is instantiated directly but there out of these only two 
has SQLStatus (ConnectionUtil.getCurrentLCC and 
JNDIAuthenticationSchemeBase.getLoginSQLException)


Another way to solve this problem can be to set a separate exception 
factory instance in InternalDriver class. If we have this in the 
beginning of boot method of InternalDriver. This instance can be static 
and once set need not be removed. Driver implementation can provide this 
factory object by a method which can be overridden by the sub class of 
InternalDriver. If the driver is booted after stopping boot method can 
skip setting the factory instance as the Driver loaded will always be 
latest version available for the jvm.


By doing this we don't have to worry about having the factory instance 
being null and there will be uniform way of creating exception across 
the code base.


anurag

anurag

Re: [jira] Updated: (DERBY-783) Enhance ALTER TABLE syntax to allow users to change the next value to be generated for an identity column

2006-01-25 Thread Satheesh Bandaram

I see previous code still being there, but under comments. Can you
remove those commented out code? Otherwise, it looks good and ready to
submit.

Satheesh

Mamta A. Satoor (JIRA) wrote:

[ http://issues.apache.org/jira/browse/DERBY-783?page=all ]

Mamta A. Satoor updated DERBY-783:
--

Attachment: Derby783AlterTableRestartWith012506.txt

The patch Derby783AlterTableRestartWith012506.txt sets the autoIncrementStart in SYSCOLUMNS t to new value provided by RESTART WITH.

svn stat
M java\engine\org\apache\derby\impl\sql\catalog\SYSCOLUMNSRowFactory.java
M java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out

Enhance ALTER TABLE syntax to allow users to change the next value to be generated for an identity column
-

Key: DERBY-783
URL: http://issues.apache.org/jira/browse/DERBY-783
Project: Derby
Type: New Feature
Components: SQL
Versions: 10.2.0.0
Reporter: Mamta A. Satoor
Assignee: Mamta A. Satoor
Attachments: Derby783AlterTableRestartWith010306.txt, Derby783AlterTableRestartWith011706.txt, Derby783AlterTableRestartWith012206.txt, Derby783AlterTableRestartWith012506.txt

Derby allows a user to change the interval between consecutive values of the identity column using ALTER TABLE. But there is no way to change the next value to be generated for an identity column. Such a support in Derby will be very handy for tables with identity column defined as GENERATED BY DEFAULT and with a unique key defined on them. Column defined with GENERATED BY DEFAULT allows system to generate values for them or allows the user to manually supply the value for them. A column defined this way is very useful when the user might want to import some data into the generated column manually. But this can create problems when the system generated values conflict with manually inserted values.
eg
autocommit on;
create table tauto(i int generated by default as identity, k int);
create unique index tautoInd on tauto(i);
insert into tauto(k) values 1,2; -- let system generate values for the identity column
-- now do few manual inserts into identity column
insert into tauto values (3,3);
insert into tauto values (4,4);
insert into tauto values (5,5);
insert into tauto values (6,6);
insert into tauto values (7,7);
insert into tauto values (8,8);
-- notice that identity column at this point has used 1 through 8
-- now if the user wants to let the system generate a value, system will generate 3 but that is already used and hence
-- insert will throw unique key failure exception. System has consumed 3 at this point.
insert into tauto(k) values 9;
-- the insert above will continue to fail with the unique key failure exceptions until system has consumed all the values till 8
-- If we add ALTER TABLE syntax to allow changing the next value to be generated, then user can simply use that to change
-- next value to be generated to 9 after the manual inserts above and then insert into tauto(k) values 9 will not fail
SQL standard syntax for changing the next generated value
ALTER TABLE tablename ALTER columnName RESTART WITH integer-constant

Re: Features of the JUnit test execution harness

2006-01-25 Thread Deepa Remesh

 One thing that would be great is if there was a well defined  way to
 have tests handle jvm specific, framework specific or version specific
 logic, since there will have to be some replacement for the many
 properties in the test harness and the individual test checks for
 framework that we have now.

I would also like to know how JUnit tests will map the current test
harness properties. My concern is specifically how to run JUnit tests
with CDC/Foundation/jsr169. I found the following test failing in this
environment: derbyall/derbyall.fail:junitTests/lang/LangSuite.java

The reason is the test uses DerbyJUnitTest.getConnection method which
uses Driver class which is not available in jsr169. For tests which
use the current test harness, ij.startJBMS() method is used to get
connections which handles getting connection on different platforms.
Can we have a similar central method to get connections in the JUnit
harness?

I think it would be good to get JUnit tests running in this
environment before we move more tests.

Thanks,
Deepa

[jira] Updated: (DERBY-678) derby documentation does not reflect changes to update lock behavior

2006-01-25 Thread Eric Radzinski (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-678?page=all ]

Eric Radzinski updated DERBY-678:
-

Attachment: derby678.diff
cdevconcepts842385.html

Attached patch address the bug that's identified in this issue.  HTML file is 
included for review.

 derby documentation does not reflect changes to update lock behavior
 

  Key: DERBY-678
  URL: http://issues.apache.org/jira/browse/DERBY-678
  Project: Derby
 Type: Bug
   Components: Documentation
 Versions: 10.0.2.0
 Reporter: Mike Matrigali
  Fix For: 10.2.0.0
  Attachments: cdevconcepts842385.html, derby678.diff

 The following section in the developers guide on update locks needs to be 
 changed from:
 When a user-defined update cursor (created with the FOR UPDATE clause) reads 
 data, its transaction obtains an update lock on the data. If the user-defined 
 update cursor updates the data, the update lock is converted to an exclusive 
 lock. If the cursor does not update the row, when the transaction steps 
 through to the next row, transactions using the TRANSACTION_READ_COMMITTED 
 isolation level release the lock, and transactions using the 
 TRANSACTION_SERIALIZABLE or TRANSACTION_REPEATABLE_READ isolation level 
 downgrade it to a shared lock until the transaction is committed. (For update 
 locks, the TRANSACTION_READ_UNCOMMITTED isolation level acts the same way as 
 TRANSACTION_READ_COMMITTED.)
 to:
 When a user-defined update cursor (created with the FOR UPDATE clause) reads 
 data, its transaction obtains an update lock on the data. If the user-defined 
 update cursor updates the data, the update lock is converted to an exclusive 
 lock. If the cursor does not update the row, when the transaction steps 
 through to the next row, transactions using the TRANSACTION_READ_COMMITTED 
 isolation level release the lock.
  (For update locks, the TRANSACTION_READ_UNCOMMITTED isolation level acts the 
 same way as TRANSACTION_READ_COMMITTED.)

-- 
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

Removing Derby tagline

We are trying to finalize the work on the Derby logo and getting this 
posted to the web site and other places.  The one issue still open is 
the tagline.  We all voted +1 for the images that had the tagline Pure 
Java Database.


It's likely that Sun has no issues with using the tagline, but it's 
taking some time to get this clarified.  In the meantime publishing the 
logo onto our site is being held back.


I wanted to see what you all felt about removing the tagline, at least 
for now.  We may in the future (potentially the near future if we get 
final clarification from Sun) have a vote to add a tagline (maybe accept 
submissions just like for the logo itself), but I wanted to know if 
there were any objections to just removing it for now.


Thanks,

David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: [jira] Commented: (DERBY-819) Provide JDBC4 SQLException subclasses support in Embedded driver

Hi, Anurag, this sounds interesting, I generally like this kind of 
approach over creating hardcoded specific SQLException classes in our 
code.  We should be able to solve this in a way that is less hardcoded 
and more flexible, which is always good for long-term maintainability.


I don't quite get your approach of having the subclasses of 
InternalDriver override the getFactory method; how does this work if the 
method is static?  I'm just having trouble picturing what the code looks 
like to get the right exception.


Just trying to work it out myself, here's a pattern I came up with, 
where everything's localized in InternalDriver and you don't need to 
override in the Driver subclasses.  It's a pretty standard factory 
pattern.  Would this work?


interface IExceptionFactory {
  createSQLException(String messageId, ...);
}

class InternalDriver {
  private static IExceptionFactory exceptionFactory_;

  public static IExceptionFactory getExceptionFactory {
if ( factory == null )
   factory = createExceptionFactory();

   return factory;
  }

  // This isn't real code, I'm just trying to get the
  // point across
  private IExceptionFactory createExceptionFactory() {
switch ( jvmVersion ) {
  case 1.3
 return new JDBC2ExceptionFactory();
  case 1.4
  case 1.5
 return new JDBC3ExceptionFactory();
  case 1.6
 return new JDBC4ExceptionFactory();
  }

  ...

}

Then in code that wants to throw an exception you say

  InternalDriver.getExceptionFactory().
createSQLException(SQLState.YADAYADA, ...);

Whaddya think???

David

Anurag Shekhar wrote:



Would it be acceptable for there to continue to be a static method in
Util that worked as it does today, always returning a
java.sql.SQLException? This method would have sanity checks to ensure
that the SQLState passed in did not start wiht any of the special values
that require specific sub-classes of SQLException. Then cases like
EmbedResultSetMetaData could use that method as the exeception it raises
does not have one of the special SQL states.


 

I have looked into the code base there are several places where 
SQLException is instantiated directly but there out of these only two 
has SQLStatus (ConnectionUtil.getCurrentLCC and 
JNDIAuthenticationSchemeBase.getLoginSQLException)


Another way to solve this problem can be to set a separate exception 
factory instance in InternalDriver class. If we have this in the 
beginning of boot method of InternalDriver. This instance can be static 
and once set need not be removed. Driver implementation can provide this 
factory object by a method which can be overridden by the sub class of 
InternalDriver. If the driver is booted after stopping boot method can 
skip setting the factory instance as the Driver loaded will always be 
latest version available for the jvm.


By doing this we don't have to worry about having the factory instance 
being null and there will be uniform way of creating exception across 
the code base.


anurag

anurag
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard

Re: Discussion of how to map the recovery time into Xmb of log --Checkpoint issue

Raymond Raymond wrote:

Mike, last time you gave me some comments about how to map the
recovery time into Xmb of log. I still have some question about it.

RR2. During initilization of Derby, we run some measurement that
RR determines the performance of the system and maps the
RR recovery time into some X megabytes of log.

RR Now, I am going to design the 2nd step first to map the recovery
RR time into some
RR X megabytes of log. A simple approach is that we can design a test
RR log file. In the
RR log file, we can let derby create a temporary database and do a
RR bunch of test to get
RR necessary disk IO information, and then delete the temporary
RR database. When derby
RR boots up, we let it to do recovery from the test log file.Anyone
RR has some other
RR suggestions on it?
MM I'll think about this, it is not straight forward. My guess would
MM be that recovery time is dominated by 2 factors:
MM 1) I/O from log disk
MM 2) I/O from data disk
MM
MM Item 1 is pretty easy to get a handle on. During redo it is pretty
MM much
MM a straight scan from beginning to end doing page based I/O. Undo is
MM harder as it jumps back and forth for each xact. I would probably
MM just
MM ignore it for estimates.
MM
MM Item 2 is totally dependent on cache rate hit you are going to
MM expect, and the number of log records.
MM The majority of log records deal with a single page, it will read
MM the page into cache if it doesn't exist and then it will do a quick
MM operation on that page. Again undo is slightly more complicated as
MM it
MM could involve logical lookups in the index.
MM
MM Another option rather than do any sort of testing is to come up with
MM an
MM initial default time based on size of log file. And then on each
MM subsequent recovery event dynamically change the estimate based on
MM how
MM long that recovery on that db took. This way each estimate will be
MM based on the actual work generated by the application, and over time
MM should become better and better.

I agree with you it is better to estimate with actual work generated by
the appplication. But, as I know, derby only performs recovery when it
boots(am I right here?). If Derby runs stably, the subsequent recovery
event you mentioned will not happen and we can't get the information we
need.

RR
RR Raymond

_
Take advantage of powerful junk e-mail filters built on patented
Microsoft® SmartScreen Technology.
http://join.msn.com/?pgmarket=en-capage=byoa/premxAPID=1994DI=1034SU=http://hotmail.com/encaHL=Market_MSNIS_Taglines
Start enjoying all the benefits of MSN® Premium right now and get the
first two months FREE*.

Yes we run recovery at boot time, and if Derby is always shutdown
cleanly then there won't be much work to do. In that case the user

should not care much that we don't have a good estimate as it seems
on that system we never do recovery. The downside is that the first
time they do recovery we may not meet the expected time of recovery
window we were aiming at.

Note we could refine the estimate from the running system by a little
by gathering average log record size. This would give an estimate
of number of possible I/O's needed to do the recovery - maybe that
along with a simple current cache hit stat that is maintained in the
system could be used.

For me it would seem ok in a zero admin db, to make a good guess at
the recovery time based on some static assumptions and then refine
the guess over time as needed using subsequent recovery events. I
really don't like the idea of slowing down every boot of the database
with a statistics gathering phase. And even slowing down every
create of the database is going to annoy some people as we have had
some users where create database time is key to their app (I believe
it was an apache project using a separate db for each test they were
running).

In a non-zero admin db I would say go ahead and implement the tests, and
then provide a way for the dba to schedule the statistics gathering.

Re: [jira] Updated: (DERBY-678) derby documentation does not reflect changes to update lock behavior

I have reviewed the attached html and it is right.  I will let the 
normal doc committers look at the source diff portion.


Eric Radzinski (JIRA) wrote:

 [ http://issues.apache.org/jira/browse/DERBY-678?page=all ]

Eric Radzinski updated DERBY-678:
-

Attachment: derby678.diff
cdevconcepts842385.html

Attached patch address the bug that's identified in this issue.  HTML file is 
included for review.



derby documentation does not reflect changes to update lock behavior


Key: DERBY-678
URL: http://issues.apache.org/jira/browse/DERBY-678
Project: Derby
   Type: Bug
 Components: Documentation
   Versions: 10.0.2.0
   Reporter: Mike Matrigali
Fix For: 10.2.0.0
Attachments: cdevconcepts842385.html, derby678.diff

The following section in the developers guide on update locks needs to be 
changed from:
When a user-defined update cursor (created with the FOR UPDATE clause) reads 
data, its transaction obtains an update lock on the data. If the user-defined 
update cursor updates the data, the update lock is converted to an exclusive 
lock. If the cursor does not update the row, when the transaction steps through 
to the next row, transactions using the TRANSACTION_READ_COMMITTED isolation 
level release the lock, and transactions using the TRANSACTION_SERIALIZABLE or 
TRANSACTION_REPEATABLE_READ isolation level downgrade it to a shared lock until 
the transaction is committed. (For update locks, the 
TRANSACTION_READ_UNCOMMITTED isolation level acts the same way as 
TRANSACTION_READ_COMMITTED.)
to:
When a user-defined update cursor (created with the FOR UPDATE clause) reads 
data, its transaction obtains an update lock on the data. If the user-defined 
update cursor updates the data, the update lock is converted to an exclusive 
lock. If the cursor does not update the row, when the transaction steps through 
to the next row, transactions using the TRANSACTION_READ_COMMITTED isolation 
level release the lock.
(For update locks, the TRANSACTION_READ_UNCOMMITTED isolation level acts the 
same way as TRANSACTION_READ_COMMITTED.)

[jira] Assigned: (DERBY-855) Document optimizer overrides which were introduced in 10.2

2006-01-25 Thread Eric Radzinski (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-855?page=all ]

Eric Radzinski reassigned DERBY-855:


Assign To: Eric Radzinski

 Document optimizer overrides which were introduced in 10.2
 --

  Key: DERBY-855
  URL: http://issues.apache.org/jira/browse/DERBY-855
  Project: Derby
 Type: Sub-task
   Components: Documentation
 Versions: 10.2.0.0
 Reporter: Mamta A. Satoor
 Assignee: Eric Radzinski
  Fix For: 10.2.0.0


 Optimizer overrides support in Derby was added as jira entry DERBY-573. Eric 
 Radzinski is working on the documentation part of the feature. This issue is 
 to keep track of documentation changes.

-- 
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

Re: Features of the JUnit test execution harness

2006-01-25 Thread Rick Hillegas


Hi Deepa,

Thanks for bringing this up. I agree that being able to run JUnit tests 
on the small device configuration would be a good idea.


Regards,
-Rick

Deepa Remesh wrote:


One thing that would be great is if there was a well defined  way to
have tests handle jvm specific, framework specific or version specific
logic, since there will have to be some replacement for the many
properties in the test harness and the individual test checks for
framework that we have now.

   


I would also like to know how JUnit tests will map the current test
harness properties. My concern is specifically how to run JUnit tests
with CDC/Foundation/jsr169. I found the following test failing in this
environment: derbyall/derbyall.fail:junitTests/lang/LangSuite.java

The reason is the test uses DerbyJUnitTest.getConnection method which
uses Driver class which is not available in jsr169. For tests which
use the current test harness, ij.startJBMS() method is used to get
connections which handles getting connection on different platforms.
Can we have a similar central method to get connections in the JUnit
harness?

I think it would be good to get JUnit tests running in this
environment before we move more tests.

Thanks,
Deepa

Class file format docs

On 1/25/06, Daniel John Debrunner [EMAIL PROTECTED] wrote:

 That should be well defined by the JVM specification and updates from
 Sun. Though I've never seen any definition of what the class major and
 minor version imply, makes it hard to generate byte code. :-(

The VM Spec hasn't been updated and I can't seem to find any
documentation as to what exactly changed between 48.0 and 49.0. Does
anyone happen to know where I can find this information?

andrew

Re: Removing Derby tagline

2006-01-25 Thread Jean T. Anderson


David W. Van Couvering wrote:
We are trying to finalize the work on the Derby logo and getting this 
posted to the web site and other places.  The one issue still open is 
the tagline.  We all voted +1 for the images that had the tagline Pure 
Java Database.


It's likely that Sun has no issues with using the tagline, but it's 
taking some time to get this clarified.  In the meantime publishing the 
logo onto our site is being held back.


I wanted to see what you all felt about removing the tagline, at least 
for now.  We may in the future (potentially the near future if we get 
final clarification from Sun) have a vote to add a tagline (maybe accept 
submissions just like for the logo itself), but I wanted to know if 
there were any objections to just removing it for now.




yes, let's remove the tagline. The logo should just include Apache 
Derby and the hat.


 -jean

[jira] Created: (DERBY-873) OSGi bundle activator not JSR169 compliant

2006-01-25 Thread Byron K. Appelt (JIRA)

OSGi bundle activator not JSR169 compliant
--

 Key: DERBY-873
 URL: http://issues.apache.org/jira/browse/DERBY-873
 Project: Derby
Type: Bug
Versions: 10.0.2.0
Reporter: Byron K. Appelt
Priority: Minor


EmbeddedActivator contains references to java.sql.DriverManager which is not 
included in JSR169.

-- 
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

Re: Removing Derby tagline

On 1/25/06, David W. Van Couvering [EMAIL PROTECTED] wrote:

 I wanted to see what you all felt about removing the tagline, at least
 for now.  We may in the future (potentially the near future if we get
 final clarification from Sun) have a vote to add a tagline (maybe accept
 submissions just like for the logo itself), but I wanted to know if
 there were any objections to just removing it for now.

Yes, please remove the tagline.

 Oh, and everyone here with a blog should link the words Java Open
Source Database to http://db.apache.org/derby in their next blog
posting to get us up in the search results. ;-)

andrew

[jira] Updated: (DERBY-599) Using setBlob interface, should not materialize the entire blob value into memory.

2006-01-25 Thread Sunitha Kambhampati (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-599?page=all ]

Sunitha Kambhampati updated DERBY-599:
--

Attachment: Derby599.diff.txt
Derby599.stat.txt

Problem:
setBlob(i,blob) does not set the length of the stream in the blob and but 
instead passes a -1 for stream length. 
During the normalization process, setBlob.normalize(DTD,DVD) calls 
SQLBlob.setWith. 
The setWidth is called in order to compare the length of the blob value to the 
maximum width of the column and to throw a truncation error in case the value 
wont fit into the column.  setWidth() calls SQLBinary.getLength().  If tvalue 
is a stream, the getLength() method checks for streamLength value and if the 
streamLength value is set to -1 (ie unknown) , it calls getBytes().length() 
which calls getValue() and this is where the entire stream is getting 
materialized.  

This patch fixes DERBY-599 so using setBlob call, will not  materialize the 
entire blob into memory. 
- changes to setBlob to pass the length of the blob value instead of -1.  The 
length of the blob value passed into setBlob can be obtained by calling 
Blob.length() which returns a long.
- move the -ve length check from setBinaryStream to setBinaryStreamInternal 
since setBlob will not pass a -1 for length.
- change setBinaryStreamInternal to take the length parameter as a long instead 
of int.  
- Currently Derby allows max value of 2G-1 ( Max value of an int) for blobs. 
Add check to ensure that if a stream with a length  max value of int is 
passed, an error is thrown. Use an existing error message 
'The resulting value is outside the range for the data type {0}'

svn stat:
M  java\engine\org\apache\derby\impl\jdbc\EmbedPreparedStatement.java
M  
java\testing\org\apache\derbyTesting\functionTests\tests\largedata\LobLimits.java
M  java\testing\org\apache\derbyTesting\functionTests\master\LobLimits.out

Tests
- Adds following testcases to largedata/LobLimits.java 
1) test for insert of 4Gb blob using setBlob api. This will throw the newly 
added error message. 
2) test for select of 2G blob and insert the 2G blob using setBlob api
3) test for select of 2G blob and update the 2G blob using setBlob api.
4) test for update of 2G blob with a 100MB blob.

Please note, the largedata/LobLimits.java does not run as part of derbyall as 
it requires large amounts of diskspace and takes a long time to run. This test 
needs to be run explicitly.

- The largedata/LobLimits test was run on a linux box - IBM 1.4.2 
jvm/RHEL4.0/insane jars and it ran successfully with no errors. Without this 
patch, there would be an outofmemory exception for the test cases mentioned 
above (except for #1).

Ran derbyall on Win2k using classes directory with Sun JVM 1.4.2.  I ran the 
network tests -derbynetmats and derbynetclientmats separately. One test failed 
- derbynetclientmats/derbynetmats/derbynetmats.fail:derbynet/NSinSameJVM.java. 
This test seems to fail intermittently. I dont believe this is related to this 
patch. 

--

I had earlier used a new error message for the case when blob length was 
greater than 2G, something like 'Blob/Clob length is greater than the supported 
length' as I didnt find anything appropriate in EmbedPreparedStatement, but 
looking more, it seemed to me - like this case would be covered by this 
existing message 'The resulting value is outside the range for the data type 
{0}' which I have used in this patch.  If someone feels otherwise, please let 
me know. 

Can someone please review this patch.  Thanks. 


 Using setBlob interface, should not materialize the entire blob value into 
 memory.
 --

  Key: DERBY-599
  URL: http://issues.apache.org/jira/browse/DERBY-599
  Project: Derby
 Type: Bug
   Components: JDBC
 Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0
  Environment: all
 Reporter: Sunitha Kambhampati
 Assignee: Sunitha Kambhampati
  Fix For: 10.2.0.0
  Attachments: Derby599.diff.txt, Derby599.stat.txt

 setBlob and blob.length() calls should not materialize blob into memory.

-- 
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

[jira] Created: (DERBY-874) Solidify JUnit test infrastructure

Solidify JUnit test infrastructure
--

 Key: DERBY-874
 URL: http://issues.apache.org/jira/browse/DERBY-874
 Project: Derby
Type: Improvement
  Components: Test  
Reporter: Rick Hillegas


Build out the JUnit test infrastructure so that developers have a clear, 
standard model to follow.

-- 
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

[jira] Assigned: (DERBY-874) Solidify JUnit test infrastructure

 [ http://issues.apache.org/jira/browse/DERBY-874?page=all ]

Rick Hillegas reassigned DERBY-874:
---

Assign To: Rick Hillegas

 Solidify JUnit test infrastructure
 --

  Key: DERBY-874
  URL: http://issues.apache.org/jira/browse/DERBY-874
  Project: Derby
 Type: Improvement
   Components: Test
 Reporter: Rick Hillegas
 Assignee: Rick Hillegas


 Build out the JUnit test infrastructure so that developers have a clear, 
 standard model to follow.

-- 
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

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

2006-01-25 Thread David Van Couvering (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12364041 ] 

David Van Couvering commented on DERBY-856:
---

I could have sworn Dan commented on this, but I can't find his email, so I'll 
say it: I think the code should use StandardException.newException() rather 
than Util.newEmbedSQLException.  This seems especially important as we look 
forward to JDBC4 support, as the recent thread with Anurag exemplifies...

So, something like

Util.generateCsSQLException(StandardException.newException(SQLState.LANG_INVALID_COLUMN_LENGTH,
 setCharacterStreamInternal));

seems more standard

David

 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

[jira] Commented: (DERBY-856) modify setCharacterStreamInternal to take a long for the length, and perform the max int check in the method

2006-01-25 Thread Sunitha Kambhampati (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-856?page=comments#action_12364044 ] 

Sunitha Kambhampati commented on DERBY-856:
---

Hi Narayanan,
As I posted a recent patch with similar changes to the setBinaryStreamInternal, 
I also looked briefly at your patch for the setCharacterStreamInternal changes. 

I have some comments. 

-- I think Dan pointed this out in a different patch. I dont think we should 
use Util.newEmbedSQLException, but instead use the newSQLException as the rest 
of the code in EmbedPreparedStatement does.

+   if (length  Integer.MAX_VALUE)
+   throw 
Util.newEmbedSQLException(SQLState.LANG_INVALID_COLUMN_LENGTH,
+   new Object[]{new 
String(setCharacterStreamInternal)},
+   StandardException.getSeverityFromIdentifier
+   (SQLState.LANG_INVALID_COLUMN_LENGTH));

-- There isnt a test to test this case where an exception would be thrown if 
the length 2G-1.  As part of my DERBY-599 patch , I added a negative test for 
blobs in largedata/LobLimits.java to test for a 4G blob. This can be extended 
for clob too similarly. 

3) The error message if a clob Integer.MAX_VALUE is sent, then the error msg 
thrown corresponds to 
42X44=Invalid length ''{0}'' in column specification.

I am not sure if the error message is appropriate here ?  For my changes to 
setBinaryStreamInternal - I used SQLState.LANG_OUTSIDE_RANGE_FOR_DATATYPE, with 
message text  'The resulting value is outside the range for the data type {0}'. 
  Also I just posted my DERBY599 patch - so maybe better to wait if someone has 
any other comments on what error message would be more appropriate. 

Thanks,
Sunitha.

 modify setCharacterStreamInternal to take a long for the length, and perform 
 the  max int check in the method
 --

  Key: DERBY-856
  URL: http://issues.apache.org/jira/browse/DERBY-856
  Project: Derby
 Type: Improvement
   Components: JDBC
 Versions: 10.2.0.0
  Environment: All Environments
 Reporter: V.Narayanan
 Assignee: V.Narayanan
 Priority: Minor
  Attachments: setCharacterStreamInternal.diff, setCharacterStreamInternal.stat

 A similar change to setBinaryStreamInternal is being handled as part of 
 DERBY-599. 

-- 
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

[jira] Updated: (DERBY-874) Solidify JUnit test infrastructure

 [ http://issues.apache.org/jira/browse/DERBY-874?page=all ]

Rick Hillegas updated DERBY-874:


Attachment: bug874.diff

The attached patch, bug874.diff, attempts to address some concerns raised by 
Dan:

o Beefed up javadoc.

o Previously swallowed exceptions are logged.

I successfully ran the CompatibilitySuite against these changes. I also ran 
derbyall. One unstable test failed: dataSourcePermissions_net under 
DerbyNetClient. However, that test ran cleanly standalone outside derbyall. 
Here are the diffs for the failed run:

*** Start: dataSourcePermissions_net jdk1.4.2_08 DerbyNetClient 
derbynetmats:derbynetmats 2006-01-25 13:56:19 ***
9a10
 org.apache.derby.iapi.services.context.ShutdownException: 
13a15
 agentThread[DRDAConnThread_4,5,derby.daemons]
Test Failed.
*** End:   dataSourcePermissions_net jdk1.4.2_08 DerbyNetClient 
derbynetmats:derbynetmats 2006-01-25 13:56:5


 Solidify JUnit test infrastructure
 --

  Key: DERBY-874
  URL: http://issues.apache.org/jira/browse/DERBY-874
  Project: Derby
 Type: Improvement
   Components: Test
 Reporter: Rick Hillegas
 Assignee: Rick Hillegas
  Attachments: bug874.diff

 Build out the JUnit test infrastructure so that developers have a clear, 
 standard model to follow.

-- 
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

Re: [jira] Updated: (DERBY-874) Solidify JUnit test infrastructure

On 1/25/06, Rick Hillegas (JIRA) derby-dev@db.apache.org wrote:

 *** Start: dataSourcePermissions_net jdk1.4.2_08 DerbyNetClient 
 derbynetmats:derbynetmats 2006-01-25 13:56:19 ***
 9a10
  org.apache.derby.iapi.services.context.ShutdownException:
 13a15
  agentThread[DRDAConnThread_4,5,derby.daemons]
 Test Failed.
 *** End:   dataSourcePermissions_net jdk1.4.2_08 DerbyNetClient 
 derbynetmats:derbynetmats 2006-01-25 13:56:5

This is most likely DERBY-273.

http://issues.apache.org/jira/browse/DERBY-273

andrew

[jira] Updated: (DERBY-273) The derbynet/dataSourcePermissions_net.java test fails intermittently

2006-01-25 Thread Andrew McIntyre (JIRA)

 [ http://issues.apache.org/jira/browse/DERBY-273?page=all ]

Andrew McIntyre updated DERBY-273:
--

Component: Regression Test Failure

 The derbynet/dataSourcePermissions_net.java test fails intermittently
 -

  Key: DERBY-273
  URL: http://issues.apache.org/jira/browse/DERBY-273
  Project: Derby
 Type: Bug
   Components: Network Server, Regression Test Failure
  Environment: 1.4.2 JVM (both Sun and IBM)
 Reporter: Jack Klebanoff
 Assignee: Tomohito Nakayama


 The test fails in the derbyall/derbynetclientmats/derbynetmats suite stack 
 with the following diff:
 *** Start: dataSourcePermissions_net jdk1.4.2 DerbyNetClient 
 derbynetmats:derbynetmats 2005-05-11 04:24:11 ***
 17a18,19
  org.apache.derby.iapi.services.context.ShutdownException: 
  agentThread[DRDAConnThread_2,5,derby.daemons]
 Test Failed.

-- 
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

[jira] Commented: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements

2006-01-25 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-866?page=comments#action_12364048 ] 

Francois Orsini commented on DERBY-866:
---

 Daniel John Debrunner commented on DERBY-866:
 -
 
 Questions on the spec:
 
 - What do you mean by familar DDL interface and known interface. Are you 
 saying that these are copied from some other database?
 

I mean that at least 2 known database systems out there are using such DDL 
interface. The CREATE USER syntax works well in respect with creating a new 
user object (such as CREATE TABLE for instance) but it not defined in the ANSI 
SQL Specs (at least I have not found any reference myself...if someone does 
please let me know). From a SQL standpoint, I find this DDL syntax in-line with 
other other DDL syntax - That's all.

 - There is no real ANSI SQL standard ... - What does this mean, is there a 
 ANSI standard that no-one implements, a pretend ANSI standard, something 
 else?
 

I have not found any ANSI SQL defining a standard syntax for SQL USER DDL 
statements, so that's what I mean by saying there is no realANSI SQL standard 
- it is all based on preference and what users would be the most familiar with 
to use as an interface, knowing that 2 other known RDBMS out are using a 
similar one.

 - What's the advantage of implementing these utility operations as DDL? The 
 same functionality can be acheived, probably at a lower footprint by using 
 procedures.
 

I thought I mentioned it in the proposal but I omitted to add the 
'Alternatives' section which would be good to have indeed - I thought it would 
be more intuitive to use a DDL SQL-like rather than calling a Derby procedure 
(again for the reasons that this syntax is similar to some used by other RDBMS).

We know tat the current interface (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) does 
NOT scale in the long run - It is based on using a database property to define 
a user in the database - It is preventing additional semantics (such as 
password expiration, default Role, etc) to be added to the user (since it is 
based on a property Name-Value pair definition right now...Sure we could use 
procedures to manage users but it won't be a structured english-like syntac 
(ala SQL)...

 - I think we need to keep a clear separation between the BUILTIN 
 authentication provider and other functionality such as roles, which should 
 be independent of authentication mechanism. Naming becomes important here, 
 SYS_BUILTIN_USERS instead of SYSUSERS, CREATE BUILTIN USER etc. It may be in 
 the future that a Derby database has users which are independent of the 
 authentication mechanism, but there is the ability to provide a mapping 
 between them. E.g. LDAP user [EMAIL PROTECTED] is mapped to user fred in a 
 Derby database.
 

I actually thought about the user mapping but did not mention it - a derby user 
should be generic enough that once authenticated in the system, it is a user, 
not a built-in user, neither an LDAP user, etc - The CREATE USER DDL command 
could be expanded with an EXTERNAL attribute to map/refer to a user outside of 
the Built-In realm and by overloading the IDENTIFIED BY attribute to specify 
the LDAP user DN (as used when authenticating with LDAP). Roles are independent 
of Users, and their relationships should be defined in separate system 
catalogs, a separate user-role-role relationship catalog can be defined to 
store the metadata about user roles or roles assigned to other roles...User 
mapping is good as there is so little control we can have over users defined in 
LDAP (in terms of settings additional user semantics in the Derby's realm), 
hence, we might need to compensate by linking an external user defined in 
Derby (i.e. SYSUSERS) with some user DN (Distinguished Name) defined in an LDAP 
repository.

Syntax such as:

CREATE USER user_id IDENTIFIED BY 'LDAP User DN' EXTERNAL

for instance: CREATE USER user_id IDENTIFIED BY 
'uid=mary,ou=People,o=FlyTours.com' EXTERNAL

The other alternative that you suggest by having a SYS_BUILTIN_USERS is 
conceivable but I was hoping to use SYSUSERS, as a system catalog not just for 
Built-In users - for instance if we need to add new user semantics such as user 
profile, role, etc, then we can map an LDAP authenticated user with a derby 
defined one with additional derby user properties (and via the EXTERNAL 
attribute). SYSUSERS can be used for the built-in provider when it is used 
or/and by other providers to map externally authenticated users whom would need 
to have additional user properties set in Derby...

--francois

 BUILT-IN Derby User Management (DDL) Enhancements
 -

  Key: DERBY-866
  URL: http://issues.apache.org/jira/browse/DERBY-866
  Project: Derby
 Type: Improvement
   Components: Security
 Versions: 10.2.0.0
 Reporter: Francois Orsini
  Fix For: 10.2.0.0

[jira] Commented: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements

2006-01-25 Thread Francois Orsini (JIRA)

[ 
http://issues.apache.org/jira/browse/DERBY-866?page=comments#action_12364050 ] 

Francois Orsini commented on DERBY-866:
---

 
 Daniel John Debrunner commented on DERBY-866:
 -
 
 What's the purpose of returning the password column in the table/vti SYSUSERS?
 
Password won't be clearly readable, only the base64 representation of a already 
hashed password - no risk really, just thought it could have some usage and if 
we use EXTERNAL to specify that this user maps to one defined in some LDAP 
repository (as an example), then because of EXTERNAL the password would not be 
encrypted and instead display the User DN ('uid=mary,ou=People,o=FlyTours.com') 
that maps into LDAP...So in that case it would have a meaning...See my previous 
comment on the EXTERNAL attribute definition. We could also decide not to 
display anything for built-in stored passwords (eventhough they cannot be 
decrypted)...

 BUILT-IN Derby User Management (DDL) Enhancements
 -

  Key: DERBY-866
  URL: http://issues.apache.org/jira/browse/DERBY-866
  Project: Derby
 Type: Improvement
   Components: Security
 Versions: 10.2.0.0
 Reporter: Francois Orsini
  Fix For: 10.2.0.0
  Attachments: Derby_User_Enhancement.html

 Proposal to enhance Derby's Built-In DDL User Management. (See proposal spec 
 attached to the JIRA).
 Abstract:
 This feature aims at improving the way BUILT-IN users are managed in Derby by 
 providing a more intuitive and familiar DDL interface. Currently (in 
 10.1.2.1), Built-In users can be defined at the system and/or database level. 
 Users created at the system level can be defined via JVM or/and Derby system 
 properties in the derby.properties file. Built-in users created at the 
 database level are defined via a call to a Derby system procedure 
 (SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY) which sets a database property.
 Defining a user at the system level is very convenient and practical during 
 the development phase (EOD) of an application - However, the user's password 
 is not encrypted and consequently appears in clear in the derby.properties 
 file. Hence, for an application going into production, whether it is embedded 
 or not, it is preferable to create users at the database level where the 
 password is encrypted.
 There is no real ANSI SQL standard for managing users in SQL but by providing 
 a more intuitive and known interface, it will ease Built-In User management 
 at the database level as well as Derby's adoption.

-- 
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

Re: Patch to take care of the ibm15 failures

On 1/23/06, Manjula G Kutty [EMAIL PROTECTED] wrote:
 Hi ,

 Can anyone go through this patch which includes the master updates for
 the recent ibm15 failures?

 Thanks
 Manjula

Hi Manjula,

Thanks for contributing this patch! I'll make a point of reviewing it tomorrow.

andrew

Re: [jira] Commented: (DERBY-866) BUILT-IN Derby User Management (DDL) Enhancements