Re: [PATCH] (DERBY-205) Rename org.apache.derby.impl.drda.DB2jServerImpl to NetworkServerControlImpl
Dag H. Wanvik wrote:
[snip]
Anyway, the name deduced for the log by NetworkServerControlImpl ends
up in NetworkServerControlImpl's private field errorLogLocation, which
in turn is used *only* (as far as i can tell) by DRDAConnThread,
through getErrorLogLocation(), to make exception strings for the
client.
Yes it is only used to reprort a log location to the client in the
message tokens for a fatal errors where the
client won't be able to call the stored procedure to retrieve message
text,
I am considering saving the name in a field
in BasicHeaderPrintWriter and extend the HeaderPrintWriter interface
to allow NetworkServerControlImpl to access it:
public void blockingStart(PrintWriter consoleWriter)
throws Exception
{
startNetworkServer();
setLogWriter(consoleWriter);
*** errorLogLocation = Monitor.getStream().getName();
cloudscapeLogWriter = Monitor.getStream().getPrintWriter();
thus getting rid of the offending code in
NetworkServerControlImpl.getPropertyInfo(). This would lead to
errorLogLocation being set *later* (not as now, by the constructor of
NetworkServerControlImpl), but it looks like it will still be set in
time (i.e. before any connections are opened).
What do you think?
I can't say I know all the implications, but I think that sounds like a
good plan.
Thanks for cleaning this up.
Kathey
[Fwd: Call for Assistance: Infrastructure]
This came out to a separate list but I thought it might be of interest to some on this list especially in light of the experience of the last couple days. Original Message Subject:Call for Assistance: Infrastructure Date: Mon, 9 May 2005 00:55:33 -0700 From: Greg Stein [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Apache Committers, As I am sure many of you are aware, the Apache Software Foundation continues to grow and develop. When the ASF was started six years ago, we had just one project: the Apache HTTP Server. There were two or three dozen committers, and one small CVS repository. Today, we have dozens of top-level projects, a hundred codebases, around a thousand committers, hundreds of mailing lists, lots of wikis, a couple bug trackers, a rack full of machines, two colocation facilities, and even further growth ahead of us. The ASF has enjoyed a lot of success with our projects and with our visibility, impact, and influence across the open source community. Heck, across the entire computing industry. Unfortunately, this growth and success comes at a cost. The administrative burden for all of this continues to increase. Our current team of volunteers need assistance. There are many ways to participate and to help out. Please subscribe to infrastructure@ and ask how you can help. You can contribute to the ASF in many more ways than coding. Your assistance can help ALL of our projects. If you have a little time, then please help our infrastructure team. Thanks, -g -- [EMAIL PROTECTED] ... ASF Chairman ... http://www.apache.org/
Re: Patch again again for DERBY-167.
Hello.
1st:
The Derby dblook utility will have to be modified to account for the BY
DEFAULT keyword--right now, it generates all autoincrement columns using
the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
2nd:
Second (minor):
I noticed that in DefaultInfoImpl.java, the two new methods
(getDefinitionBitsValue and calcIsDefaultValueAutoinc) are declared as
static--is there a reason for that? I made them non-static and everything
compiled, so I'm just wondering if this was intentional?
Yes. That was intentional.
I prefer static method because it have narrower scope than instance method.
Static method can not access instance variable.
On the contrast , calling instance method would change instance variable ,
and state of the object so on.
Then , I prefer static method than instance methood.
I know method , which are to be overridden , must be instance method.
But I think those methods which I added was not such methods.
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
- Original Message -
From: Army [EMAIL PROTECTED]
To: Derby Development derby-dev@db.apache.org
Sent: Tuesday, May 17, 2005 9:50 AM
Subject: Re: Patch again again for DERBY-167.
TomohitoNakayama wrote:
Hello.
I send new patch for DERBY-167 , which is attached to this mail.
Please review it.
Thanks for the sending the new patch.
I've reviewed it and I have the following comments. The first one is an
important one, the second one is very minor.
First:
The Derby dblook utility will have to be modified to account for the BY
DEFAULT keyword--right now, it generates all autoincrement columns using
the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
Since your patch sets the DefaultInfo for a BY DEFAULT column to a
non-null value, I think dblook can just check the COLUMNDEFAULT column
in the SYS.SYSCOLUMNS table. If it is _not_ null, then dblook can
generate BY DEFAULT instead of ALWAYS.
For example, you could change the getAutoIncStmt statement at the top of
DB_Table.java to retrieve the COLUMNDEFAULT column:
getAutoIncStmt =
conn.prepareStatement(SELECT AUTOINCREMENTSTART, +
AUTOINCREMENTINC, COLUMNDEFAULT FROM SYS.SYSCOLUMNS +
WHERE COLUMNNAME = ? AND REFERENCEID = ?);
and then change the reinstateAutoIncrement(...) method to do the
following:
.
.
.
if (autoIncCols.next()) {
long start = autoIncCols.getLong(1);
if (!autoIncCols.wasNull()) {
colDef.append( GENERATED );
// -- begin new logic --
String def = autoIncCols.getString(3);
colDef.append(autoIncCols.wasNull() ? ALWAYS : BY DEFAULT);
// -- end new logic --
colDef.append( AS IDENTITY (START WITH );
colDef.append(autoIncCols.getLong(1));
colDef.append(, INCREMENT BY );
colDef.append(autoIncCols.getLong(2));
colDef.append());
}
}
This will make it so that dblook generates BY DEFAULT correctly for
columns that require it.
And then it'd probably be good to add a case for this in
java/testing/org/apache/derbyTesting/tests/tools/dblook_makeDB.sql, which
is the script that is used for testing dblook. In that script, there's a
section under the Tables heading that indicates auto increment/default
test cases. You could add a simple table for the GENERATED BY DEFAULT
case. If you have any problems getting that to work, feel free to post
your questions and I'll try to help where I can.
Second (minor):
I noticed that in DefaultInfoImpl.java, the two new methods
(getDefinitionBitsValue and calcIsDefaultValueAutoinc) are declared as
static--is there a reason for that? I made them non-static and everything
compiled, so I'm just wondering if this was intentional?
Thanks again for re-sending the patch, and please feel free to ask if you
have any questions about I've written here.
Army
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.11 - Release Date: 2005/05/16
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.12 - Release Date: 2005/05/17
Re: Patch again again for DERBY-167.
Hello. ColumnDefinitionNode: I would like to see following comments be more descriptive. Initially I thought these refer to another method, but that is not the case. +//validateDefaultOfAutoInc +//validateDefaultOfDefault Firstly I thought make each part as separated method. But I abort it because separated method will make it difficult to see how instance variable of defaultInfo are handled. I will write a English sentence there. ColumnDescriptor.java: Is there an extra assert for autoincInc being non-zero at line: 156 I will erase unnecessary part... Also 'static' is not needed for assertAutoinc() method. As written in reply mail for Army , I prefer static method . How should do it ...? Best regards. /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ - Original Message - From: Satheesh Bandaram To: Derby Development Sent: Wednesday, May 18, 2005 10:00 AM Subject: Re: Patch again again for DERBY-167. Thanks for applying review comments. Overall, the patch looks good. Some minor comments: ColumnDefinitionNode: I would like to see following comments be more descriptive. Initially I thought these refer to another method, but that is not the case. +//validateDefaultOfAutoInc +//validateDefaultOfDefault ColumnDescriptor.java: Is there an extra assert for autoincInc being non-zero at line: 156? (Second constructor). Also 'static' is not needed for assertAutoinc() method. Please apply Army's and my comments. I also invite others to review the patch, since I will be looking to commit this one soon, after getting an updated patch. :-) Satheesh TomohitoNakayama wrote: Hello. I send new patch for DERBY-167 , which is attached to this mail. Please review it. Best regards. /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */ - Original Message - From: Army [EMAIL PROTECTED] To: Derby Development derby-dev@db.apache.org Sent: Saturday, May 14, 2005 9:13 AM Subject: Re: Patch again for DERBY-167. TomohitoNakayama wrote: Hello. I send new patch for DERBY-167. Please review it again. I tried to apply this patch to my local codeline (which I just updated) so that I could review it more closely, but the patch fails to apply in several places. I know it's annoying, but could you perhaps svn update your codeline and then re-create the patch based on the latest files? If I can get the patch to apply, it makes it easier to review the code. Also, I can then run the new/updated tests and verify that everything works as intended... Thanks, Army -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 2005/05/13 No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 2005/05/13 No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.12 - Release Date: 2005/05/17 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.11.12 - Release Date: 2005/05/17
[jira] Resolved: (DERBY-104) Get rid of the Max lenght of 18 for constraint names
[ http://issues.apache.org/jira/browse/DERBY-104?page=all ] Bernt M. Johnsen resolved DERBY-104: Resolution: Fixed Get rid of the Max lenght of 18 for constraint names Key: DERBY-104 URL: http://issues.apache.org/jira/browse/DERBY-104 Project: Derby Type: Wish Reporter: Bernd Ruehlicke Assignee: Bernt M. Johnsen Priority: Minor Attachments: derby-id-plus-renames-v2.patch If not unlimited than we should at least make them 80 (just to pick a abitrary number) -- 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 again again for DERBY-167.
TomohitoNakayama wrote:
Hello.
1st:
The Derby dblook utility will have to be modified to account for the
BY DEFAULT keyword--right now, it generates all autoincrement
columns using the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
The dblook changes could be a separate patch. Incremental development
is a good process, rather than requiring all the related changes to
be in one huge patch.
2nd:
Second (minor):
I noticed that in DefaultInfoImpl.java, the two new methods
(getDefinitionBitsValue and calcIsDefaultValueAutoinc) are declared as
static--is there a reason for that? I made them non-static and
everything compiled, so I'm just wondering if this was intentional?
Yes. That was intentional.
I prefer static method because it have narrower scope than instance method.
I agree, static methods are the correct type here.
I would encourage you (and anyone else) to keep any description (or
modified version of it) from the original patch e-mail in newer e-mails
with modified patches. This makes it easier for the committers to
understand and track patches. E.g. you last Derby-167 patch just had the
patch attached, you should keep any description from the first e-mail
with the patch. Another reason is that the description may have changed
due to comments etc.
In general the patch looks good, thanks for making changes for my
previous feedback.
Some minor comments on the patch:
In ResultSetNode and ColumnDefintionNode for this line you changed
if (defaultInfo != null ! colDesc.isAutoincrement())
it would be good to add some descriptive comment. The issue here is that
the test is two negative conditions 'anded ()' together. Somewhat hard
for humans (well at least me) to understand quickly. A comment is also
useful for the original coder to help them ensure they have the correct
condition.
BITS_MASK_IS_DEFAULTVALUE_AUTOINC should be 'final' if it is intended to
be a constant.
In DefaultInfoImpl the calculating of definitionBits and
isDefaultValueAutoinc using those static methods seems too complex. If
there are ever a few more types to calculate we end up with a lot of
code to deal with it. Why not just have a single instance field
representing the type (matching your defintion bits), remove
isDefaultValueAutoinc field. Then the read/writeExternal methods just
write the type directly, and the isDefaultValueAutoinc method is
something like
+ public boolean isDefaultValueAutoinc(){
+ return (type BITS_MASK_IS_DEFAULTVALUE_AUTOINC) != 0;
+ }
Dan.
Re: Atomicity of using IDENTITY_VAL_LOCAL()
Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn statM java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction.Except it doesn't behave like that, with respect to the *currenttransaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection.See the example below, and note auto commit is true.And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1,that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single rowINSERT statement within the same connection.Dan.ij connect 'jdbc:derby:foo;create=true';ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deletedij insert into t(d) values(88);1 row inserted/updated/deletedij values IDENTITY_VAL_LOCAL();1---11 row selectedij select * from t; ID |D---1|881 row selectedij values IDENTITY_VAL_LOCAL();1---11 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (working copy) @@ -719,7 +719,25 @@ -- notice that committing the transaction does not affect IDENTITY_VAL_LOCAL() commit; values IDENTITY_VAL_LOCAL(); +-- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); drop table t1; drop table t2; +-- A table with identity column has an insert trigger which inserts into another table +-- with identity column. IDENTITY_VAL_LOCAL will return the generated value for the +-- statement table and not for the table that got modified by the trigger +create table t1 (c11 int generated always as identity (start with 101, increment by 3), c12 int); +create table t2 (c21 int generated always as identity (start with 201, increment by 5), c22 int); +create trigger t1tr1 after insert on t1 for each row mode db2sql insert into t2 (c22) values (1); +values IDENTITY_VAL_LOCAL(); +insert into t1 (c12) values (1); +-- IDENTITY_VAL_LOCAL will return 101 which got generated for table t1. +-- It will not return 201 which got generated for t2 as a result of the trigger fire. +values IDENTITY_VAL_LOCAL(); +select * from t1; +select * from t2; +drop table t1; +drop table t2; + Index: java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out === --- java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out (working copy) @@ -1431,8 +1431,46 @@ 1 --- 201 +ij(CONN2) -- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); +1 +--- +201 ij(CONN2) drop table t1; 0 rows inserted/updated/deleted ij(CONN2) drop table t2; 0 rows inserted/updated/deleted +ij(CONN2) -- A table with identity column has an insert
RE: Atomicity of using IDENTITY_VAL_LOCAL()
Hello everyone. How can I remove myself from this mailing list? I tried mailing the "unsubscribe" address, but I'm still here... Thanks. -Original Message-From: Mamta Satoor [mailto:[EMAIL PROTECTED]Sent: Wednesday, May 18, 2005 4:39 PMTo: Derby DevelopmentSubject: Re: Atomicity of using IDENTITY_VAL_LOCAL() Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn statM java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction.Except it doesn't behave like that, with respect to the *currenttransaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection.See the example below, and note auto commit is true.And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1,that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single rowINSERT statement within the same connection.Dan.ij connect 'jdbc:derby:foo;create=true';ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deletedij insert into t(d) values(88);1 row inserted/updated/deletedij values IDENTITY_VAL_LOCAL();1---11 row selectedij select * from t; ID |D---1|881 row selectedij values IDENTITY_VAL_LOCAL();1---11 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (working copy) @@ -719,7 +719,25 @@ -- notice that committing the transaction does not affect IDENTITY_VAL_LOCAL() commit; values IDENTITY_VAL_LOCAL(); +-- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); drop table t1; drop table t2; +-- A table with identity column has an insert trigger which inserts into another table +-- with identity column. IDENTITY_VAL_LOCAL will return the generated value for the +-- statement table and not for the table that got modified by the trigger +create table t1 (c11 int generated always as identity (start with 101, increment by 3), c12 int); +create table t2 (c21 int generated always as identity (start with 201, increment by 5), c22 int); +create trigger t1tr1 after insert on t1 for each row mode db2sql insert into t2 (c22) values (1); +values IDENTITY_VAL_LOCAL(); +insert into t1 (c12) values (1); +-- IDENTITY_VAL_LOCAL will return 101 which got generated for table t1. +-- It will not return 201 which got generated for t2 as a result of the trigger fire. +values
Re: [PATCH] Derby-203 - setNull(x,JDBCType.DATE) does not work when batching is turned on
Shreyas Kaushik wrote:
Hi all,
Please find attached the patch for this. I have updated JIRA with the
test diffs and test output files.
With this patch I have attempted to fix the problem that occurs with
setNull when batching is turned on for all datatypes
where this problem existed. I had earlier fixed a similar problem for
Blob and Timestamp only, unknowing that this could occur
elsewhere. This patch I feel address this aspect.
Please review the patch.
Looks good, I'll work on committing it assuming no other review comments.
+/** Adding this method to ensure that super class' setInto method
doesn't get called
+ * that leads to the violation of JDBC spec( untyped nulls ) when
batching is turned on.
+ */
+public void setInto(PreparedStatement ps, int position) throws
SQLException, StandardException {
Much better job on the comments though in Dan's ideal world there would
be a little more. Things to think about in future comments:
- Comments often miss the 'why', which can be the essential piece of
information. E.g. a comment such as 'Need to do something here.' is
crying out for a 'why', 'Need to do something here because blah.'
In your comment it's not clear why there is a violation of the JDBC spec.
- To fully understand this comment you need to look at the super-class'
setInto method, but that method may not always exist. Thus if some
cleanup [re]moves that method, this comment becomes much harder to
understand. Thus ensure comments are failrly stand-alone.
[I think the parent setInto method could be moved into UserType]
- Separate out functionality of the method from how it is used, the
previous implementation (using the super's method) was incorrect
regardless of how it was called. Batching was one example. This is
similar to the discussion on the methods Jack is adding for timestampDiff.
Here is an example of the same comment which addresses these points.
/**
Set this DATE value into a PreparedStatement. Uses the explicit
PreparedStatement.setDate() to ensure that the NULL value is passed
in as a null 'typed' as a DATE, implicitly typed by the use of setDate().
The generic PreparedStatement.setObject() cannot be used, as the NULL
value will be passed as an 'untyped' null which violates the JDBC spec
and will cause an exception to be thrown.
Previous use of setObject() in a common setInto method caused batching
to fail with DATE parameters, see Derby 203.
*/
Thanks,
Dan.
RE: Atomicity of using IDENTITY_VAL_LOCAL()
I've had the same problem as Mirit. -Original Message-From: Mirit Naim [mailto:[EMAIL PROTECTED]Sent: Wednesday, May 18, 2005 9:08 AMTo: 'Derby Development'Subject: RE: Atomicity of using IDENTITY_VAL_LOCAL() Hello everyone. How can I remove myself from this mailing list? I tried mailing the "unsubscribe" address, but I'm still here... Thanks. -Original Message-From: Mamta Satoor [mailto:[EMAIL PROTECTED]Sent: Wednesday, May 18, 2005 4:39 PMTo: Derby DevelopmentSubject: Re: Atomicity of using IDENTITY_VAL_LOCAL() Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn statM java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction.Except it doesn't behave like that, with respect to the *currenttransaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection.See the example below, and note auto commit is true.And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1,that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single rowINSERT statement within the same connection.Dan.ij connect 'jdbc:derby:foo;create=true';ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deletedij insert into t(d) values(88);1 row inserted/updated/deletedij values IDENTITY_VAL_LOCAL();1---11 row selectedij select * from t; ID |D---1|881 row selectedij values IDENTITY_VAL_LOCAL();1---11 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (working copy) @@ -719,7 +719,25 @@ -- notice that committing the transaction does not affect IDENTITY_VAL_LOCAL() commit; values IDENTITY_VAL_LOCAL(); +-- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); drop table t1; drop table t2; +-- A table with identity column has an insert trigger which inserts into another table +-- with identity column. IDENTITY_VAL_LOCAL will return the generated value for the +-- statement table and not for the table that got modified by the trigger +create table t1 (c11 int generated always as identity (start with 101, increment by 3), c12 int); +create
Re: Atomicity of using IDENTITY_VAL_LOCAL()
Hi Mitri, To unsubscribe, send an email to [EMAIL PROTECTED]or [EMAIL PROTECTED]depending on how you are subscribed to the mailing list.http://incubator.apache.org/derby/derby_mail.html has more information about various Derb mailing lists. Mamta On 5/18/05, Mirit Naim [EMAIL PROTECTED] wrote: Hello everyone. How can I remove myself from this mailing list? I tried mailing the unsubscribe address, but I'm still here... Thanks. -Original Message-From: Mamta Satoor [mailto: [EMAIL PROTECTED]]Sent: Wednesday, May 18, 2005 4:39 PMTo: Derby DevelopmentSubject: Re: Atomicity of using IDENTITY_VAL_LOCAL() Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn statM java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction.Except it doesn't behave like that, with respect to the *currenttransaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection.See the example below, and note auto commit is true.And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1,that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single rowINSERT statement within the same connection.Dan.ij connect 'jdbc:derby:foo;create=true';ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deletedij insert into t(d) values(88);1 row inserted/updated/deletedij values IDENTITY_VAL_LOCAL();1---11 row selectedij select * from t; ID |D---1|881 row selectedij values IDENTITY_VAL_LOCAL();1---11 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (working copy) @@ -719,7 +719,25 @@ -- notice that committing the transaction does not affect IDENTITY_VAL_LOCAL() commit; values IDENTITY_VAL_LOCAL(); +-- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); drop table t1; drop table t2; +-- A table with identity column has an insert trigger which inserts into another table +-- with identity column. IDENTITY_VAL_LOCAL will return the generated value for the +-- statement table and not for the table that got modified by the trigger +create table t1 (c11 int generated always as identity (start with 101, increment by 3), c12 int); +create table t2 (c21 int generated always as identity (start with 201, increment by 5), c22 int); +create trigger t1tr1 after insert on t1 for each row mode db2sql insert into t2 (c22) values (1); +values IDENTITY_VAL_LOCAL(); +insert into t1 (c12) values (1); +-- IDENTITY_VAL_LOCAL will return 101 which got generated for table t1. +-- It will not return 201 which got generated for t2 as a result of the trigger fire. +values IDENTITY_VAL_LOCAL(); +select * from t1; +select * from t2; +drop table t1; +drop table t2; + Index: java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out === --- java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out
Re: Patch again again for DERBY-167.
Hello.
Daniel John Debrunner wrote:
1st:
The Derby dblook utility will have to be modified to account for the
BY DEFAULT keyword--right now, it generates all autoincrement
columns using the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
The dblook changes could be a separate patch. Incremental development
is a good process, rather than requiring all the related changes to
be in one huge patch.
Well
I just have started modification of dblook.
Then I will include it.
But if encountered some problem , I will postpone it for other task.
if (defaultInfo != null ! colDesc.isAutoincrement())
it would be good to add some descriptive comment. The issue here is that
the test is two negative conditions 'anded ()' together. Somewhat hard
for humans (well at least me) to understand quickly. A comment is also
useful for the original coder to help them ensure they have the correct
condition.
Well
This condition is surely difficult.
Comment will be needed .
I will add.
Sometimes comment can be barrier for reading code.
Therefore, I hesitate to write comment.
BITS_MASK_IS_DEFAULTVALUE_AUTOINC should be 'final' if it is intended to
be a constant.
In DefaultInfoImpl the calculating of definitionBits and
isDefaultValueAutoinc using those static methods seems too complex. If
there are ever a few more types to calculate we end up with a lot of
code to deal with it. Why not just have a single instance field
representing the type (matching your defintion bits), remove
isDefaultValueAutoinc field. Then the read/writeExternal methods just
write the type directly, and the isDefaultValueAutoinc method is
something like
+ public boolean isDefaultValueAutoinc(){
+ return (type BITS_MASK_IS_DEFAULTVALUE_AUTOINC) != 0;
+ }
I hesitated calculating each time calling isDefaultValueAutoinc() method.
Well But its very small price.
Price of calculating each time will correspond to simple code.
I will modify it.
Best regards.
/*
Tomohito Nakayama
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
- Original Message -
From: Daniel John Debrunner [EMAIL PROTECTED]
To: Derby Development derby-dev@db.apache.org
Sent: Wednesday, May 18, 2005 10:22 PM
Subject: Re: Patch again again for DERBY-167.
TomohitoNakayama wrote:
Hello.
1st:
The Derby dblook utility will have to be modified to account for the
BY DEFAULT keyword--right now, it generates all autoincrement
columns using the ALWAYS keyword. See
org/apache/derby/impl/tools/dblook/DB_Table.java, in the
reinsateAutoIncrement method. Luckily, this change should be fairly
easy given the changes in your patch.
I see.
I will modify dblook.
Thank you for your notifying :D
The dblook changes could be a separate patch. Incremental development
is a good process, rather than requiring all the related changes to
be in one huge patch.
2nd:
Second (minor):
I noticed that in DefaultInfoImpl.java, the two new methods
(getDefinitionBitsValue and calcIsDefaultValueAutoinc) are declared as
static--is there a reason for that? I made them non-static and
everything compiled, so I'm just wondering if this was intentional?
Yes. That was intentional.
I prefer static method because it have narrower scope than instance
method.
I agree, static methods are the correct type here.
I would encourage you (and anyone else) to keep any description (or
modified version of it) from the original patch e-mail in newer e-mails
with modified patches. This makes it easier for the committers to
understand and track patches. E.g. you last Derby-167 patch just had the
patch attached, you should keep any description from the first e-mail
with the patch. Another reason is that the description may have changed
due to comments etc.
In general the patch looks good, thanks for making changes for my
previous feedback.
Some minor comments on the patch:
In ResultSetNode and ColumnDefintionNode for this line you changed
if (defaultInfo != null ! colDesc.isAutoincrement())
it would be good to add some descriptive comment. The issue here is that
the test is two negative conditions 'anded ()' together. Somewhat hard
for humans (well at least me) to understand quickly. A comment is also
useful for the original coder to help them ensure they have the correct
condition.
BITS_MASK_IS_DEFAULTVALUE_AUTOINC should be 'final' if it is intended to
be a constant.
In DefaultInfoImpl the calculating of definitionBits and
isDefaultValueAutoinc using those static methods seems too complex. If
there are ever a few more types to calculate we end up with a lot of
code to deal with it. Why not just have a single instance field
representing the type (matching your defintion bits), remove
isDefaultValueAutoinc field. Then the
RE: Atomicity of using IDENTITY_VAL_LOCAL()
What Mirit is saying is that your suggestion does not work. I share in Mirit's experience. I've unsubscribed to every possible Derby subscription *twice* and still get the emails. The unsubscribe feature is *broken*. Kevyn -Original Message-From: Mamta Satoor [mailto:[EMAIL PROTECTED]Sent: Wednesday, May 18, 2005 9:25 AMTo: Derby DevelopmentSubject: Re: Atomicity of using IDENTITY_VAL_LOCAL() Hi Mitri, To unsubscribe, send an email to [EMAIL PROTECTED]or [EMAIL PROTECTED]depending on how you are subscribed to the mailing list.http://incubator.apache.org/derby/derby_mail.html has more information about various Derb mailing lists. Mamta On 5/18/05, Mirit Naim [EMAIL PROTECTED] wrote: Hello everyone. How can I remove myself from this mailing list? I tried mailing the "unsubscribe" address, but I'm still here... Thanks. -Original Message-From: Mamta Satoor [mailto: [EMAIL PROTECTED]]Sent: Wednesday, May 18, 2005 4:39 PMTo: Derby DevelopmentSubject: Re: Atomicity of using IDENTITY_VAL_LOCAL() Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn statM java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sqlM java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction.Except it doesn't behave like that, with respect to the *currenttransaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection.See the example below, and note auto commit is true.And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1,that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single rowINSERT statement within the same connection.Dan.ij connect 'jdbc:derby:foo;create=true';ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deletedij insert into t(d) values(88);1 row inserted/updated/deletedij values IDENTITY_VAL_LOCAL();1---11 row selectedij select * from t; ID |D---1|881 row selectedij values IDENTITY_VAL_LOCAL();1---11 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++
Re: Planning for a 10.1 release
Andrew McIntyre wrote: Hello derby-dev, Now that there have been some significant new contributions to Derby since 10.0.2.1 was released, I think we should begin planning for a 10.1 release. As promised earlier, I'll volunteer to be release manager. So, here goes: [snip] Feel free to add to this list and I'll keep track of all the responses. 6) The 10.1 current manuals have an *experimental* format according to http://incubator.apache.org/derby/manuals/index.html#10.1+Alpha+Manuals Not sure what is experimental about their current format, but this should be resolved to a non-experimental format. Thanks, Dan.
Re: [jira] Updated: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Kathey Marsden wrote: Gosh, I know I must sound like a broken record, but I am having trouble applying this patch. I tried with both patch directly and with eclipse. Eclipse complains that NetworkServerControlImpl.java doesn't exist which I am guessing is an issue becauase it is a new file, but I am synched up and the file does exist. Incase you synched up your svn client outside of eclipse, one thing to try would be to refresh the project before applying the patch. Sunitha.
Re: Planning for a 10.1 release
I have had a report internally where we have 2 unit tests fail with the DerbyNetwork client driver that did not fail with the DB2 type 4 driver with Derby. We have not had a chance to look into this yet in detail yet. If we can package up the failure, are there any volunteers on the IBM side who have access to the DB2 jdbc driver code to see why there might be a difference in behavior? For packaging, let us include the frameworks directory which has the scripts for the networkserver (btw did you get a chance to commit the patch i had sent to add the derbyclient support?) Regards, lance Mamta Satoor wrote: Hi Andrew, I am working on getting JDBC updatable resultset functionality working for Network Server using Derby Net Client. Will send a patch in couple days if not earlier. Mamta On 5/17/05, Andrew McIntyre [EMAIL PROTECTED] wrote: Hello derby-dev, Now that there have been some significant new contributions to Derby since 10.0.2.1 was released, I think we should begin planning for a 10.1 release. As promised earlier, I'll volunteer to be release manager. So, here goes: 1) Are there any new features or significant bugfixes near completion that should be in the 10.1 release? Dan mentioned that he would like to have his JSR-169 work included, Tomohito's fix for Derby-167 looks nearly complete, and David V.C. has a couple of items that look like they might be done soon. Any estimates on when these will be completed? Anything else not mentioned here? 2) Are there any currently opened JIRA entries that should be considered showstoppers for this release? Any upgrade issues definitely need to be sorted out and tested, maybe we should have a JIRA for this. Documentation of new features should be finalized. I think there may already be a JIRA entry for this. 3) Which bugs would be nice-to-have in this release but are not showstoppers? I personally would like to see the patch for Derby-1 committed. 4) Are there any issues surrounding the client that should be addressed before it is released? This deserves its own thread, and there's already one started here: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200505.mbox/[EMAIL PROTECTED] That thread got quiet, but I'll respond to that mail to keep the discussion going. 5) Are there any changes to the packaging that people would like to see for this release? Feel free to add to this list and I'll keep track of all the responses. andrew
[jira] Commented: (DERBY-220) Javadoc build should include a timestamp and/or the svn revision number in a visible location.
[ http://issues.apache.org/jira/browse/DERBY-220?page=comments#action_65663 ] Dyre Tjeldvoll commented on DERBY-220: -- I've thought a bit about this, and I'm wondering about exactly which revision and timestamp you want: a) Do you want the most recent revision for the repository, or the most recent revision in which something (in Derby) changed? The first one is already available as the changeversion property, and could easily be added to the javadoc footer. (I guess that, ideally, one would want the revision in which something that affects the javadoc was changed. But I don't think that's feasible...) b) About the timestamp; do you mean the the time when the javadoc command was run, or the time when the revision in a) was committed to the repository? Consider the output from svn info, standing in trunk: [EMAIL PROTECTED]/local/d_rby-220$ svn info Path: . URL: https://svn.apache.org/repos/asf/incubator/derby/code/trunk Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 Revision: 170751 -- This is the same as the changedversion property Node Kind: directory Schedule: normal Last Changed Author: bandaram Last Changed Rev: 170695 -- This is the last revision in which something in trunk changed Last Changed Date: 2005-05-18 03:15:14 +0200 (Wed, 18 May 2005) -- And this is the corresponding date Properties Last Updated: 2005-05-13 16:10:24 +0200 (Fri, 13 May 2005) It is fairly simple to add the raw output from svn info to the javadoc footer, but this is probably overkill. It also clutters up the footer and takes up quite a bit of screen real-estate. It would be trivial to write a shell-script that filters the output, but this would not be portable. One could let a java program to do the filtering, but one would still be relying on the output from svn info being stable... I don't know if it is. A different approach would be to include the Subversion keywords (LastChangedRevision and LastChangedDate or Id) in the javadoc description for each class. You would have to change every file (and remember to set the svn:keyword property), but this could be done by a script. The diff would be huge, though... Does the reporter (or anyone else) have any comments on this? Javadoc build should include a timestamp and/or the svn revision number in a visible location. -- Key: DERBY-220 URL: http://issues.apache.org/jira/browse/DERBY-220 Project: Derby Type: Improvement Components: Build tools Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Priority: Minor Fix For: 10.1.0.0 In order to easily identify when a specific set of javadoc was built, and from what source, it would be useful to include a timestamp and/or the svn revision number at the time the javadoc is built. The footer is an excellent location to place this information, as it is visible on every generated page. -- 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: Planning for a 10.1 release
Daniel John Debrunner wrote: 6) The 10.1 current manuals have an *experimental* format according to http://incubator.apache.org/derby/manuals/index.html#10.1+Alpha+Manuals Not sure what is experimental about their current format, but this should be resolved to a non-experimental format. Jeff posted numerous disclaimers about the initial format. I'm happy to remove the word experimental. Experience on other apache lists demonstrates that this may be it. Of course, anyone should feel free to jump in a help tweak the format. -jean
Re: [jira] Updated: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Hi, Kathey. NetworkServerControlImpl is the new name for DB2jServerImpl, based on the fix that Dag made. Perhaps your svn update didn't pick up the name change? Try creating a completely new copy of the codeline and applying the patch there... David Kathey Marsden wrote: David Van Couvering (JIRA) wrote: Attached is the patch that should resolve this item. I relocated the execute method from NetworkServerImpl (previously called DB2jServerImpl) to NetworkServerControl. Gosh, I know I must sound like a broken record, but I am having trouble applying this patch. I tried with both patch directly and with eclipse. With patch I get: patching file `java/drda/org/apache/derby/impl/drda/NetworkServerControlImpl.java' Assertion failed: hunk, file patch.c, line 321 Eclipse complains that NetworkServerControlImpl.java doesn't exist which I am guessing is an issue becauase it is a new file, but I am synched up and the file does exist. David, would you mind making sure you are synched up and then resending the patch via email. Sometimes that works better. If anyone else has any other ideas on how to get Eclipse or patch to accept this patch, I would really appreciate it. Kathey
Re: Jira seems whacked [fixed]
both problems look fixed. -jean Jean T. Anderson wrote: I just now resolved DERBY-272 as fixed, but none of our version entries appear to be in the system, though our components still are. Also I can't open a new issue. After hitting the Next button for Step 1 of 2: Choose the project and issue type I get An exception occurred: java.util.NoSuchElementException. I'll report it to infrastructure. -jean
Re: Planning for a 10.1 release
Lance J. Andersen wrote: I have had a report internally where we have 2 unit tests fail with the DerbyNetwork client driver that did not fail with the DB2 type 4 driver with Derby. We have not had a chance to look into this yet in detail yet. If we can package up the failure, are there any volunteers on the IBM side who have access to the DB2 jdbc driver code to see why there might be a difference in behavior? I think the issue should be addressed in terms of the Derby client only and not any IBM code. Let's see what the issue is once you have a reproducible case. Dan.
[jira] Closed: (DERBY-288) JDBC 2.0 Connection Methods Supported table in displays correctly in html but not in pdf form of Reference manual
[ http://issues.apache.org/jira/browse/DERBY-288?page=all ] Jean T. Anderson closed DERBY-288: -- Resolution: Fixed Committed, revision 170790, patch in derby288modified.zip that fixes the display problem with JDBC 2.0 Connection Methods Supported table in the Reference manual. JDBC 2.0 Connection Methods Supported table in displays correctly in html but not in pdf form of Reference manual - Key: DERBY-288 URL: http://issues.apache.org/jira/browse/DERBY-288 Project: Derby Type: Bug Components: Documentation Reporter: Mamta A. Satoor Fix For: 10.1.0.0 Attachments: derby288modified.zip Reference manual has JDBC 2.0 Connection Methods Supported table. This table shows up correctly when viewed in html http://incubator.apache.org/derby/docs/ref/rrefjdbc80004.html but not in PDF form. Basically, it does not extend the implementation notes for createStatement to prepareStatement and prepareCall. -- 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-271) Document the new property derby.system.durability=test
[ http://issues.apache.org/jira/browse/DERBY-271?page=all ] Jean T. Anderson closed DERBY-271: -- Resolution: Fixed Fix Version: 10.1.0.0 Committed, revision 170786, patch in derby271modifiedfinal.zip that adds documentation for the new derby.system.durability property to the Tuning Guide. Document the new property derby.system.durability=test -- Key: DERBY-271 URL: http://issues.apache.org/jira/browse/DERBY-271 Project: Derby Type: Sub-task Components: Documentation Versions: 10.1.0.0 Reporter: Sunitha Kambhampati Assignee: Jeff Levitt Fix For: 10.1.0.0 Attachments: derby271modifiedfinal.zip Need to document the new property - derby.system.durability This should probably go along with other properties in Tuning guide. -- derby.system.durability Currently the only valid supported case insensitive value is 'test' If this property is set to any other value other than 'test', this property setting is ignored In the future, this property can be used to set different modes of durability - for example a form of relaxed durability where database can recover to a consistent state, or to enable some kind of in-memory mode. When set to 'test', the store system will not force sync calls in the following cases - for the log file at each commit - for the log file before data page is forced to disk - for page allocation when file is grown - for data writes during checkpoint That means - a commit no longer guarantees that the transaction's modification will survive a system crash or JVM termination - the database may not recover successfully upon restart - a near full disk at runtime may cause unexpected errors - database can be in an inconsistent state This setting is provided for performance reasons and should ideally only be used when the system can withstand the above consequences. One sample use would be to use this mode (derby.system.durability=test) when using Derby as a test database, where high performance is required and the data is not very important. If database is booted with derby.system.durability=test, the following warning message is logged in derby.log WARNING: The database is booted with derby.system.durability=test. In this mode, it is possible that database may not be able to recover, committed transactions may be lost, database may be in an inconsistent state. Please use this mode only when these consequences are acceptable and a similar message will appear in derby.log if the database was booted with derby.system.durability=test at any time previously. It is important to realize that once the database is booted with derby.system.durability=test, there are no guarantees on if the database is consistent or not. --- Valid supported values are test Example derby.system.durability=test One can set this as a command line option to the JVM when starting the application or in the derby.properties file. It is a system level property. This property is static; if you change it while Derby is running, the change does not take effect until you reboot. -- 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] increasinng the possible log file id's from 2^22 -1 to 2^33 -1 (derby-101)
Requiring that to downgrade would make log code easier, but that is not the requirement. Currently we support unclean shutdowns in n+1 and must be able to recover when brought up in n. Also even in a clean shutdown we leave at least one log file around with the checkpoint log record of the last checkpoint. This is how we tell there is nothing to do. Logically as you say, we could add a new code path to delete all the log files if we are shutting down, have locked out all possible updates, and make sure that failing in the middle of deleting log files does not leave a wierd state. Also if the database has been backed up in rollforward mode, we need all the log files even after a checkpoint - so that would not work in that case. David Van Couvering wrote: Sorry, perhaps a dumb question here -- I'm still learning how Derby works. If someone wants to downgrade from revision N+1 to revision N, wouldn't they normally shut down the database prior to downgrade, in which case the data gets checkpointed and the log files wouldn't be needed? Thanks, David Mike Matrigali wrote: I am looking at committing this. The changes look good to me, but I believe there are upgrade issues to handle. For a hard upgrade either new or old databases are fine. For a soft upgrade I think there is a problem if the db generates enough log files to start using the new bits, and then the software is reverted to before the fix. Seems like using the bits needs to be somehow only enabled for hard upgrade. It would be best if it was controlled just by hard upgrade, but if that is not possible then just doing it for databases created since this version would also work - but still leave problems with old hard upgraded databases. I have reviewed the code and am running tests. I plan on committing this part of the fix and let you address upgrade issues with a follow on patch. Suresh Thalamati wrote: Attached is the patch to increase the max possible log files number from 2^22 -1 to 2^33 -1. Derby creates log file names in sequential order by incrementing log file number by one each time(like log1.dat logN.dat). id's are not reused, so the last possible log file that can be created currently is limited to 2^22 - 1 (4194303). Problem with this limit is , it can be possible hit on systems that creates lot of log records very fast with the default log file size (1MB) , for example if 1MB of log is created every second this limit can be hit in (4194303 / (60 * 60 * 24)) 48 days. Attached fix bumps the max possible log file number to 2^33 -1 by borrowing some unused bits in the log file number and log file size fields in the log instant. With the same assumption as above if a a 1MB of log file is created for every second; it will take ((8589934591 / (60 * 60 * 24))/365) approximately 272 years; Which I think is a reasonable limit. :-) I believe the new limit is a reasonable one , and not necessary to solve this problem by implementing a complicated solution that reuse the ids, at this moment. Testing : ran derbyall ; all tests passed. New tests : Added couple of tests to test the max log file ids using debug flags. svn status M java\engine\org\apache\derby\impl\store\raw\log\LogCounter.java M java\engine\org\apache\derby\impl\store\raw\log\LogToFile.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumberRecovery_derby.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumber_app.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumberRecovery_app.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumber_derby.properties A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumber.java A java\testing\org\apache\derbyTesting\functionTests\tests\store\MaxLogNumberRecovery.java A java\testing\org\apache\derbyTesting\functionTests\master\MaxLogNumber.out A java\testing\org\apache\derbyTesting\functionTests\master\MaxLogNumberRecovery.out M java\testing\org\apache\derbyTesting\functionTests\suites\storerecovery.runall $ Thanks -suresht Index: java/engine/org/apache/derby/impl/store/raw/log/LogCounter.java === --- java/engine/org/apache/derby/impl/store/raw/log/LogCounter.java (revision 170490) +++ java/engine/org/apache/derby/impl/store/raw/log/LogCounter.java (working copy) @@ -62,13 +62,15 @@ public static final long INVALID_LOG_INSTANT = 0; -// reserve top 10 bits in log file number for future use -public static final long MAX_LOGFILE_NUMBER= (long)0x003FL;// 4194303 -private static final long FILE_NUMBER_SHIFT= 32; +// max possible log file number
[jira] Closed: (DERBY-249) Builds fail during splitmessages step if path contains spaces
[ http://issues.apache.org/jira/browse/DERBY-249?page=all ] Samuel Andrew McIntyre closed DERBY-249: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 revisions 170793 (10.1) and 170782 (10.0) Builds fail during splitmessages step if path contains spaces - Key: DERBY-249 URL: http://issues.apache.org/jira/browse/DERBY-249 Project: Derby Type: Bug Components: Build tools Versions: 10.0.2.2, 10.1.0.0 Reporter: Samuel Andrew McIntyre Assignee: Dyre Tjeldvoll Priority: Trivial Fix For: 10.0.2.2, 10.1.0.0 Attachments: derby-249.diff, derby-249.status, derbyall_report.txt If the path to the Derby source files contains a space, for example /opt/My Local Drive/derbysource, then the build will fail at the splitmessages step with the following error: [java] Exception in thread main java.lang.StringIndexOutOfBoundsException: String index out of range: -1 [java] at java.lang.String.substring(String.java:1444) [java] at org.apache.derbyBuild.splitmessages.main(splitmessages.java:44) splitmessages should be improved to handle spaces in the path to the message files. -- 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] increasinng the possible log file id's from 2^22 -1 to 2^33 -1 (derby-101)
It's actually a good question David, I also heard of other database which has this requirement. In derby users are not requied to shutdown the datbase before doing upgrade/ downgrade , I think is is to make Derby Zero-Admin database. Any changes to the logging system also have to handle upgrade/downgrade issues. Thanks -suresht David Van Couvering wrote: Sorry, perhaps a dumb question here -- I'm still learning how Derby works. If someone wants to downgrade from revision N+1 to revision N, wouldn't they normally shut down the database prior to downgrade, in which case the data gets checkpointed and the log files wouldn't be needed? Thanks, David Mike Matrigali wrote: I am looking at committing this. The changes look good to me, but I believe there are upgrade issues to handle. For a hard upgrade either new or old databases are fine. For a soft upgrade I think there is a problem if the db generates enough log files to start using the new bits, and then the software is reverted to before the fix. Seems like using the bits needs to be somehow only enabled for hard upgrade. It would be best if it was controlled just by hard upgrade, but if that is not possible then just doing it for databases created since this version would also work - but still leave problems with old hard upgraded databases. I have reviewed the code and am running tests. I plan on committing this part of the fix and let you address upgrade issues with a follow on patch. Suresh Thalamati wrote:
Re: Planning for a 10.1 release
Daniel John Debrunner wrote: Lance J. Andersen wrote: I have had a report internally where we have 2 unit tests fail with the DerbyNetwork client driver that did not fail with the DB2 type 4 driver with Derby. We have not had a chance to look into this yet in detail yet. If we can package up the failure, are there any volunteers on the IBM side who have access to the DB2 jdbc driver code to see why there might be a difference in behavior? I think the issue should be addressed in terms of the Derby client only and not any IBM code. I agree. I guess what i was trying to say is that I assume that the bulk of the new client driver is a stripped down version of the IBM DB2 driver so that if you could run the test side by side using both drivers and are able to compare the source, it might be easier to figure out where the disconnect is based on the port of the code. If that is not possible, there is always the old fashioned way ;-) Let's see what the issue is once you have a reproducible case. I am waiting on this from the QA team as it is part of a pretty big test harness. Once I have this, i will enter a jira. Dan.
[jira] Created: (DERBY-299) NetworkServerControlImpl should not have Hard coded message for Unexpected expections
NetworkServerControlImpl should not have Hard coded message for Unexpected expections - Key: DERBY-299 URL: http://issues.apache.org/jira/browse/DERBY-299 Project: Derby Type: Bug Components: Network Server Versions: 10.0.2.2, 10.1.0.0 Reporter: Kathey Marsden When this work is done there is a incorrectly hard coded exception String in that should be evaluated and removed. protected final static String UNEXPECTED_ERR = Unexpected exception; All messages should be localized, but this might be a bit tricky as there seems to be some places where this string is expicitly checked. Might be best addressed in conjunction with DERBY-294 Move argument processing out of NetworkServerControlImpl -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
rollforward will not work correctly if the system happens to crash immediately after rollforward backup. - Key: DERBY-298 URL: http://issues.apache.org/jira/browse/DERBY-298 Project: Derby Type: Bug Components: Store Versions: 10.0.2.1 Reporter: Suresh Thalamati Priority: Minor If the system crashes after a rollforward backup; last log file is empty(say log2.dat). On next crash-recovery system ignores the empty log file and starts writing to the previous log(say log1.dat), even thought there was successfule log file switch before the crash. The reason I belive it is done this way to avoid special handling of crashes during the log switch process. Problem is on rollfroward restore from a backup log1.dat will get overwritten from the copy in the backup, so any transaction that got added to log1.dat after the backup was taken will be lost. One possible solution that comes to my mind to solve this problem is 1) check if an empty a log file exist after a redo crash-recovery , if the log archive mode is enabled. 2) If it exists , delete and do log file switch again Repro: connect 'jdbc:derby:wombat;create=true'; create table t1(a int ) ; insert into t1 values(1) ; insert into t1 values(2) ; call SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE( 'extinout/mybackup', 0); --crash (NO LOG RECORDS WENT IN AFTER THE BACKUP). connect 'jdbc:derby:wombat'; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; insert into t1 select a*2 from t1 ; select count(*) from t1 ; --exit from jvm and restore from backup connect 'jdbc:derby:wombat;rollForwardRecoveryFrom=extinout/mybackup/wombat'; select count(*) from t1 ; -- THIS WILL GIVE INCORRECT VALUES -- 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: Atomicity of using IDENTITY_VAL_LOCAL()
Submitted this patch. Satheesh Mamta Satoor wrote: Hi Satheesh, Sorry for both the gottchas. Here is the new patch with right files. thanks, Mamta On 5/17/05, Satheesh Bandaram [EMAIL PROTECTED] wrote: Mamta, looks like this patch was sent to wrong alias... Should it be sent to DerbyDev? :-) Also this patch seems to include a modification to 'java/client/org/apache/derby/client/am/ResultSet.java' that I suspect should not be in the patch. If so, can you remove that and resubmit? Satheesh Mamta Satoor wrote: Hi, I have another small patch for trigger test for IDENTITY_VAL_LOCAL. Can a committer please commit it for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sql M java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Mamta Satoor [EMAIL PROTECTED] wrote: Hi, I will file a doc JIRA entry for the IDENTITY_VAL_LOCAL() function, so there is the crucial *connection* dependency identified. Also, I have added one more subtest to autoincrement.sql which tests the return value of this function for 2 different connections. Can someone commit the patch for me? svn stat M java\testing\org\apache\derbyTesting\functionTests\tests\lang\autoincrement.sql M java\testing\org\apache\derbyTesting\functionTests\master\autoincrement.out * thanks, Mamta On 5/13/05, Daniel John Debrunner [EMAIL PROTECTED] wrote: Mamta Satoor wrote: The SELECT IDENTITY_VAL_LOCAL() FROM mytable1 will return the value that got into generated for _any_ table with identity column using single row insert with values clause in the current transaction. Except it doesn't behave like that, with respect to the *current transaction*. Derby's implementation returns the last identity value for a single row INSERT statement within the same connection. See the example below, and note auto commit is true. And it makes no sense to do a SELECT IDENTITY_VAL_LOCAL() FROM mytable1, that will just return the same value multiple times (once per row in the table) and the value will be the last identity value for a single row INSERT statement within the same connection. Dan. ij connect 'jdbc:derby:foo;create=true'; ij create table t (id int generated always as identity, d int); 0 rows inserted/updated/deleted ij insert into t(d) values(88); 1 row inserted/updated/deleted ij values IDENTITY_VAL_LOCAL(); 1 --- 1 1 row selected ij select * from t; ID |D --- 1|88 1 row selected ij values IDENTITY_VAL_LOCAL(); 1 --- 1 1 row selected Index: java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql === --- java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (revision 170188) +++ java/testing/org/apache/derbyTesting/functionTests/tests/lang/autoincrement.sql (working copy) @@ -719,7 +719,25 @@ -- notice that committing the transaction does not affect IDENTITY_VAL_LOCAL() commit; values IDENTITY_VAL_LOCAL(); +-- notice that rolling the transaction does not affect IDENTITY_VAL_LOCAL() +values IDENTITY_VAL_LOCAL(); drop table t1; drop table t2; +-- A table with identity column has an insert trigger which inserts into another table +-- with identity column. IDENTITY_VAL_LOCAL will return the generated value for the +-- statement table and not for the table that got modified by the trigger +create table t1 (c11 int generated always as identity (start with 101, increment by 3), c12 int); +create table t2 (c21 int generated always as identity (start with 201, increment by 5), c22 int); +create trigger t1tr1 after insert on t1 for each row mode db2sql insert into t2 (c22) values (1); +values IDENTITY_VAL_LOCAL(); +insert into t1 (c12) values (1); +-- IDENTITY_VAL_LOCAL will return 101 which got generated for table t1. +-- It will not return 201 which got generated for t2 as a result of the trigger fire. +values IDENTITY_VAL_LOCAL(); +select * from t1; +select * from t2; +drop table t1; +drop table t2; + Index: java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out === --- java/testing/org/apache/derbyTesting/functionTests/master/autoincrement.out (revision 170188) +++
Re: [PATCH] test harness sed.java readme
On May 17, 2005, at 3:51 PM, Dag H. Wanvik wrote: MvL == Myrna van Lunteren [EMAIL PROTECTED] wrote: MvL From looking at functionTests/harness/Sed.java after some trouble MvL reported because of directory names, I noticed there was a lot of old MvL - let's call it: - stuff that wasn't needed anymore. So, this patch MvL contains a slightly cleaned up file. Would this also fix Derby-266? Or should that be closed and just called out in docs, too? It appears from the description of Derby-266 that this patch would fix that issue. Myrna, a couple things: Reviewing this patch is rather difficult because it includes a lot of format changes mixed in with code that has been altered or removed. I'm not against reformatting, Sed.java is a particularly bad offender, but formatting changes should be in a separate diff. Also, you didn't mention it in your original mail whether or not you ran derbyall and whether or not it passed. And, a JIRA should probably be filed for the fact that the test harness can't run in a path that contains spaces. andrew
[jira] Commented: (DERBY-211) Network Server returns no result sets for a procedure call that returns no result
[ http://issues.apache.org/jira/browse/DERBY-211?page=comments#action_65698 ] David Van Couvering commented on DERBY-211: --- What is the right behavior? Should we return no results or a result with a zero update count? My intuition says no results makes more sense, but perhaps we should make the network server be consistent with the embedded behavior... Network Server returns no result sets for a procedure call that returns no result - Key: DERBY-211 URL: http://issues.apache.org/jira/browse/DERBY-211 Project: Derby Type: Bug Components: Network Server Versions: 10.1.0.0 Reporter: Kathey Marsden For a call of a procedure with no dynamic results embedded Cloudscape returns a one result, an update count of zero. However, using the network server no results are returned. We should be consistent. To reproduce See call za() in lang/procedure.java test. -- 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-248) Network Server frameworks scripts should support Derby network client driver
[ http://issues.apache.org/jira/browse/DERBY-248?page=all ] Samuel Andrew McIntyre closed DERBY-248: Resolution: Fixed Fix Version: 10.1.0.0 patch committed in revision 170821 Network Server frameworks scripts should support Derby network client driver Key: DERBY-248 URL: http://issues.apache.org/jira/browse/DERBY-248 Project: Derby Type: Improvement Components: Demos/Scripts Versions: 10.1.0.0 Reporter: Samuel Andrew McIntyre Assignee: Lance Andersen Fix For: 10.1.0.0 Currently the Network Server framework scripts expect the client driver to be the IBM Universal JDBC Driver (JCC). The Network Server framework scripts should be enhanced to support the Derby network client driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
[ http://issues.apache.org/jira/browse/DERBY-51?page=comments#action_65710 ] David Van Couvering commented on DERBY-51: -- I can't seem to reproduce this behavior (see attached modification to the test derbynet/NSInSameJVM.java). I also looked in the code for NetworkServerControlImpl, and the code that shuts down embedded seems to be commented out -- see the commented out code at the end of NetworkServerControlImpl.blockingStart(), starting with // Shutdown Cloudscape. So, unless I missed something, it appears that right now the Derby system does *not* get shut down when the Network Server is stopped. Is it that we need an API that makes this an optional behavior? Or are things OK as they stand? Need NetworkServerControl shutdown API method that does not shutdown derby embedded --- Key: DERBY-51 URL: http://issues.apache.org/jira/browse/DERBY-51 Project: Derby Type: Improvement Components: Network Server Versions: 10.0.2.0 Reporter: Kathey Marsden Attachments: NSinSameJVM.java In an applcation server environment where both Network Server and Embedded connections are being used it is a problem when Network server is shutdown and deregisters the embedded driver and shutsdown the databases. this would be the signature /** * Shutdown a Network Server. * Shuts down the Network Server listening on the port and InetAddress * specified in the constructor for this NetworkServerControl object. * * @param derbyShutdown if true, shutsdown the derby embedded system . if false do not shutdown derby embeddded system * @exception Exceptionthrows an exception if an error occurs */ public void shutdown(boolean derbyShutdown) throws Exception -- 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-51) Need NetworkServerControl shutdown API method that does not shutdown derby embedded
[ http://issues.apache.org/jira/browse/DERBY-51?page=all ] David Van Couvering updated DERBY-51: - Attachment: NSinSameJVM.java This modification to NSinSameJVM.java ensures that an embedded connection is usable after shutdown of the Network Server. Running the test produced no failures... Need NetworkServerControl shutdown API method that does not shutdown derby embedded --- Key: DERBY-51 URL: http://issues.apache.org/jira/browse/DERBY-51 Project: Derby Type: Improvement Components: Network Server Versions: 10.0.2.0 Reporter: Kathey Marsden Attachments: NSinSameJVM.java In an applcation server environment where both Network Server and Embedded connections are being used it is a problem when Network server is shutdown and deregisters the embedded driver and shutsdown the databases. this would be the signature /** * Shutdown a Network Server. * Shuts down the Network Server listening on the port and InetAddress * specified in the constructor for this NetworkServerControl object. * * @param derbyShutdown if true, shutsdown the derby embedded system . if false do not shutdown derby embeddded system * @exception Exceptionthrows an exception if an error occurs */ public void shutdown(boolean derbyShutdown) throws Exception -- 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: Updated snapshot jars
One more observation on Linux using the tar.gz download today: Every shell script (e.g. frameworks/NetworkServer/bin/ij.ksh) appears to have a similarly named file with .rej appended. Is that the result of a failed patch script that didn't get caught? Dan On 4/30/05, Dan Scott [EMAIL PROTECTED] wrote: Andrew: Gave 10.1 alpha it a quick shot in Network Server mode on Windows today. One quick observation: setNetworkServerCP.bat sets the CLASSPATH to point to the derby.jar, etc. files in DERBY_INSTALL/lib/ -- however, in the ZIP file the jar files are in the root directory. I had to modify setNetworkSetCP.bat accordingly to get the CLASSPATH set up correctly. At a minimum, either the batch file should be updated, or the zip file should be placed entirely within a /lib/ directory (which is kind of a generic name.) Ideally, all of the files should be contained in a descriptively named directory (derby, perhaps), and the batch file should be updated to match. Dan On 4/29/05, Andrew McIntyre [EMAIL PROTECTED] wrote: Hello all, This afternoon I updated the snapshot jars posted on the downloads page. It would be great for anyone interested in the Derby network client driver which was recently added to the trunk (10.1.0.0 alpha), or any other recently added feature or bugfix in which you are interested, to test them out and report your findings. Those interested in testing Derby on their favorite platform/JVM will find the corresponding derbyTesting.jar in the snapshot file. Also, please note that the zip snapshots were generated on Windows and the tar.gz snapshots were generated on Unix, so text files in the snapshots should have the proper line endings. Here are the highlights for each new snapshot: 10.1.0.0 alpha - FOR TESTING ONLY. Please see the warning about using alpha releases on the downloads page: http://incubator.apache.org/derby/derby_downloads.html#Development+trunk - Derby network client driver added. Use the included derbyclient.jar in place of db2jcc.jar. Additional information on its use can be found in the functional specification attached to this post: http://article.gmane.org/gmane.comp.apache.db.derby.devel/2960 - DATE and TIMESTAMP functions which correctly match the documentation - First phase of online compress functionality - Derby-176: queries with extensive joins no longer cause java linkage error - Derby-186: Set currentPosition for scrollable cursors when moving past the last row - Derby-134: Improvement to allow ordering by expressions, instead of correlation names or column positions only. - Derby-96: beginning support for recovery from out-of-order log records - Derby-106: spill BackingStoreHashTables to disk to prevent out of memory errors in hash joins - DERBY-158: PRIMARY KEY does not imply NOT NULL - INTERSECT/EXCEPT support - Preliminary JSR169 support - Snapshot includes demo and scripts - Fixed Eclipse plugin version specification - Lots more that I've left out :-) 10.0.2.2 - please note that this is not an official release - LOCAL is no longer a reserved keyword - Demos and scripts included in the snapshot - Fixed Eclipse plugin version specification A full list of fixed bugs in each version can be found here: http://issues.apache.org/jira/secure/BrowseProject.jspa? id=10594subset=-1 andrew
[PATCH] MacOS X BUILDING.txt
From: Andrew McIntyre [EMAIL PROTECTED]> Date: May 17, 2005 8:03:22 PM PDT To: Derby Development derby-dev@db.apache.org> Subject: Re: Mac OSX build requirements On May 17, 2005, at 2:19 PM, Craig Russell wrote: I would be happy to write up a patch for BUILDING.txt or wherever it should be. I just happen to be looking at some build/documentation related items right now. I think it would be fine to put this information into BUILDING, since it is key to building Derby on Mac OS X. If you produce a patch, I'll review and commit it. Once you have it built, you'll probably want to look over DERBY-1 if you haven't already: http://issues.apache.org/jira/browse/DERBY-1 Thanks. I've incorporated the information from DERBY-1 into the proposed update to the BUILDING.txt, which you will find attached. The patch is based on revision 170836. Thanks, Craig andrew MacOSX-BUILDING.diff Description: Binary data Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp! smime.p7s Description: S/MIME cryptographic signature
[jira] Closed: (DERBY-196) Link for Jikes 1.14 in BUILDING.txt needs to be changed to http://jikes.sourceforge.net/
[ http://issues.apache.org/jira/browse/DERBY-196?page=all ] Samuel Andrew McIntyre closed DERBY-196: Resolution: Fixed Fix Version: 10.0.2.2 10.1.0.0 revisions 170837 (10.1) and 170838 (10.0) Link for Jikes 1.14 in BUILDING.txt needs to be changed to http://jikes.sourceforge.net/ Key: DERBY-196 URL: http://issues.apache.org/jira/browse/DERBY-196 Project: Derby Type: Improvement Components: Documentation Reporter: John Sisson Priority: Trivial Fix For: 10.0.2.2, 10.1.0.0 Attachments: patch.txt The Jikes project is now hosted at SourceForge. The link for Jikes 1.14 in BUILDING.txt needs to be changed to http://jikes.sourceforge.net/ -- 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: [doc] Proposal to move 10.0 doc files from derby/site to derby/docs [Last call for objections]
On 5/14/05, Jean T. Anderson [EMAIL PROTECTED] wrote: This change is in place and the web site changes are live on incubator.apache.org/derby . From my poking, it seems stable. Please report any problems. Now that we have a real 10.0 doc branch, should I remove the doc set that's included in the 10.0 code branch? Or should I update it with a build from the 10.0 doc branch? The 10.0 branch isn't seeing much action, but I suppose it might be useful to have a set of docs checked in somewhere in case there happens to be a need to make a 10.0 release sometime in the future. Anyone have an opinion on this? andrew
Re: [PATCH] test harness sed.java readme
To check, you want me to: 1. make a separate patch for Sed.java without any formatting. 2. another one for the readme.txt. 3. log a bug for the spaces not working fix that with the readme.txt patch ? I think Jeremy was planning on doing a whole formatting thing - so I'll see if I can undo those changes redo the others and let Jeremy handle the formatting. And of course I ran all tests. Should've said so. Of course, now I have to run them again. Will post a new patch tomorrow. or so. Myrna On 5/18/05, Andrew McIntyre [EMAIL PROTECTED] wrote: On May 17, 2005, at 3:51 PM, Dag H. Wanvik wrote: MvL == Myrna van Lunteren [EMAIL PROTECTED] wrote: MvL From looking at functionTests/harness/Sed.java after some trouble MvL reported because of directory names, I noticed there was a lot of old MvL - let's call it: - stuff that wasn't needed anymore. So, this patch MvL contains a slightly cleaned up file. Would this also fix Derby-266? Or should that be closed and just called out in docs, too? It appears from the description of Derby-266 that this patch would fix that issue. Myrna, a couple things: Reviewing this patch is rather difficult because it includes a lot of format changes mixed in with code that has been altered or removed. I'm not against reformatting, Sed.java is a particularly bad offender, but formatting changes should be in a separate diff. Also, you didn't mention it in your original mail whether or not you ran derbyall and whether or not it passed. And, a JIRA should probably be filed for the fact that the test harness can't run in a path that contains spaces. andrew
Re: [jira] Commented: (DERBY-296) Document
I would agree... I think the right thing to do would be to fix the code. David Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
some typo in Derby Optimizer Design
Hi, Thanks for the clear write-up on derby optimizer ( http://incubator.apache.org/derby/papers/optimizer.html ). Here are a couple of typo in the article. table name t1 should be t2 in the following paragraph where I marked [-- t2] : Let's say this partial plan has an estimated cost of 2000. Now suppose the optimizer considers placing the table t1 [-- t2] as the next table in the join order: (outer) t4 - t5 - t2 (inner) Note that the query has no direct join clause between t1 [-- t2] and either t4 or t5. The optimizer would go through all possible access paths for t2 in this context, and would see that with no useful qualification on the table it would have to do a full scan of t2 for every outer row resulting from the join of t4 and t5. Jim Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
Re: [doc] Proposal to move 10.0 doc files from derby/site to derby/docs [Last call for objections]
Just keep in mind that derby/docs/branches/10.0 just has doc source. The pages built from that source are not committed to the svn repo. --This is how other apache projects handle forrest-generated stuff. -jean Andrew McIntyre wrote: On 5/14/05, Jean T. Anderson [EMAIL PROTECTED] wrote: This change is in place and the web site changes are live on incubator.apache.org/derby . From my poking, it seems stable. Please report any problems. Now that we have a real 10.0 doc branch, should I remove the doc set that's included in the 10.0 code branch? Or should I update it with a build from the 10.0 doc branch? The 10.0 branch isn't seeing much action, but I suppose it might be useful to have a set of docs checked in somewhere in case there happens to be a need to make a 10.0 release sometime in the future. Anyone have an opinion on this? andrew
Re: [jira] Commented: (DERBY-296) Document
David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
Re: Planning for a 10.1 release
Andrew McIntyre wrote: Hello derby-dev, 1) Are there any new features or significant bugfixes near completion that should be in the 10.1 release? Dan mentioned that he would like to have his JSR-169 work included, Tomohito's fix for Derby-167 looks nearly complete, and David V.C. has a couple of items that look like they might be done soon. Any estimates on when these will be completed? Anything else not mentioned here? Jeremy could you comment on the changes that you made to ClientDataSource? Is there follow up work that you still need to do there for the release? r168355 | jboynes | 2005-05-05 10:00:08 -0700 (Thu, 05 May 2005) | 1 line move all generic implementation into ClientBaseDataSource r168336 | jboynes | 2005-05-05 07:35:57 -0700 (Thu, 05 May 2005) | 1 line code cleanup on client DataSource impls Kathey
[STATUS] (Derby) Wed May 18 23:45:28 2005
APACHE DERBY STATUS:
Last modified at [$Date: 2005-02-10 15:37:41 -0500 (Thu, 10 Feb 2005) $] by
$Author: fuzzylogic $.
Web site: http://incubator.apache.org/derby/
Incubator Status
Description
Derby is a snapshot of the IBM's Cloudscape Java relational database. IBM is
opening the code by contributing it to The Apache Software Foundation and
basing future versions of IBM Cloudscape on the Apache-managed code.
To participate in the Derby podling, you should join the mailing list. Just
send an empty message to [EMAIL PROTECTED] .
The initial goal of the project while in incubation is to build a viable
developer community around the codebase.
The second goal of Derby-in-incubation is to successfully produce a release.
Since Derby is in incubation, such a release would not have formal standing;
it will serve as a proof-of-concept to demonstrate to the developers' and
incubator's satisfaction that this aspect of the project is health and
understood.
Project info
* The Apache DB project will own the Derby subproject, and the subproject will
follow the Apache DB PMC's direction. Significant contributors to this sub-
project (for example, after a significant interval of sustained
contribution)
will be proposed for commit access to the codebase.
* The Derby sub-project's modules will be available as distinct and discrete
downloads.
Detailed References:
itemtype reference
Status file www http://incubator.apache.org/projects/derby.html
Website www http://incubator.apache.org/derby/
Mailing listdev derby-dev@db.apache.org
Mailing listusers derby-user@db.apache.org
Source code SVN /repos/asf/incubator/derby/code/trunk/
Mentor coar Ken Coar (CLA on file)
Committers jta Jean Anderson (CLA on file)
Committers satheesh Satheesh Bandaram (CLA on file)
Committers jboynes Jeremy Boynes (CLA on file)
Committers djd Daniel Debrunner (CLA on file)
Committers kmarsden Katherine Marsden (CLA on file)
Committers mikem Mike Matrigali (CLA on file)
Committers mcintyre Samuel McIntyre (CLA on file)
Committers coar Ken Coar (CLA on file)
Completed tasks are shown by the completion date (-MM-dd).
Incubation status reports
* none yet
Incubation work items
Project Setup
Identify the codebase
dateitem
...-..-.. If applicable, make sure that any associated name does not already
exist and check www.nameprotect.com to be sure that the name is not
already trademarked for an existing software product.
Copyright
dateitem
2004-08-26 Check and make sure that the papers that transfer rights to the ASF
been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project.
2004-11-04 Check and make sure that the files that have been donated have been
updated to reflect the new ASF copyright.
Verify distribution rights
dateitem
2004-10-12 Check that all active committers have a signed CLA on record.
2004-10-12 Remind active committers that they are responsible for ensuring that
a Corporate CLA is recorded if such is is required to authorize
their contributions under their individual CLA.
2004-10-12 Check and make sure that for all items included with the
distribution
that is not under the Apache license, we have the right to combine
with Apache-licensed code and redistribute.
2004-10-12 Check and make sure that all items depended upon by the project is
covered by one or more of the following approved licenses: Apache,
BSD, Artistic, MIT/X, MIT/W3C, MPL 1.1, or something with
essentially
the same terms.
Generally, the result of checking off these items will be a Software Grant,
CLA, and Corporate CLA for ASF licensed code, which must have no dependencies
upon items whose licenses that are incompatible with the Apache License.
Organizational acceptance of responsibility for the project
* Has the receiving PMC voted to accept it? **YES**
Releases:
None so far. A first release is in progress. This first release will be
versioned 10.0.2.1.
PENDING ISSUES
==
Derby documentation in PDF format:
A request was made for PDF documentation, however, the source files for the
current HTML documentation for Derby are not in a form useful for creating PDF
documentation with Forrest. A proposal was made by Jeff Levitt
[EMAIL PROTECTED] to convert the documentation into XML DITA format.
RESOLVED ISSUES SINCE LAST STATUS
=
[VOTE] on repository layout:
[ Ten votes ] Option 1: Keep the code and site pages in
separately-versionable
trees ( derby/site/{trunk,tags,branches}/pages and
Re: [jira] Commented: (DERBY-296) Document
I could do this; every time I talk to customers they hammer into me that clear and helpful error messages are key. It would *really* help if I knew which message texts were modified in the doc. Is it limited to the Derby-specific messages with SQLStates starting with X? Would I submit this as an independent patch to the same JIRA item? Note also that I may find bugs in the messages that would require a redo of the documentation... David Jean T. Anderson wrote: David Van Couvering wrote: I would agree... I think the right thing to do would be to fix the code. David is that an offer? :-) -jean Jean T. Anderson (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-296?page=comments#action_65717 ] Jean T. Anderson commented on DERBY-296: Regarding this: During my work, I discovered that many of the messages could use some spellchecking, grammar checking, etc. Rather than document them this way, I corrected them. At some point a separate JIRA issue should be made, and someone should undertake the task of fixing the actual message strings to reflect the correct grammar, spelling, punctuation, etc. used in this document. I'm concerned users might be confused if the error message an application spits out does not exactly match the error message string documented in the Reference Manual. I think this work shouldn't be committed until doc matches code (whether it involves changing the messages in this patch or modifying the code to match these). Document Key: DERBY-296 URL: http://issues.apache.org/jira/browse/DERBY-296 Project: Derby Type: Task Components: Documentation Environment: all Reporter: Jeff Levitt Assignee: Jeff Levitt Priority: Minor Attachments: derby296.zip I've spent some time compiling a list of error messages for Derby, to expand on the error messages section currently in the Reference Manual. I am about ready to submit a candidate patch, and I am opening up a JIRA issue to contain it.
Re: [jira] Updated: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
David Van Couvering (JIRA) wrote: Attached is the patch that should resolve this item. Hi David, I committed this patch #:) Committed revision 170862. If you have not signed an Indivicual Contributor License agreement yet, please consider doing so. See: http://www.apache.org/licenses/ Kathey
[jira] Commented: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
[ http://issues.apache.org/jira/browse/DERBY-214?page=comments#action_65734 ] Kathey Marsden commented on DERBY-214: -- I committed this patch. Sendingjava\drda\org\apache\derby\drda\NetworkServerControl.java Sending java\drda\org\apache\derby\impl\drda\NetworkServerControlImpl.java Sending java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testconnection.java Transmitting file data ... Committed revision 170862. 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.0.0 Reporter: Kathey Marsden Assignee: David Van Couvering 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
Re: [jira] Updated: (DERBY-214) Remove System.exit() calls from the DB2jServerImpl.java
Great, thanks. I have submitted an ICLA. David Kathey Marsden wrote: David Van Couvering (JIRA) wrote: Attached is the patch that should resolve this item. Hi David, I committed this patch #:) Committed revision 170862. If you have not signed an Indivicual Contributor License agreement yet, please consider doing so. See: http://www.apache.org/licenses/ Kathey
[jira] Commented: (DERBY-243) connection toString should uniquely identify the connection
[ http://issues.apache.org/jira/browse/DERBY-243?page=comments#action_65735 ] Kathey Marsden commented on DERBY-243: -- I performed only a very rough review of this diff. I am hoping someone else can do a more detailed review once the following issues have been resolved. 1) I tend to think that it is confusing to have a separate UUID for the client connection. In a client server environment, each connection has two separate UUID's, which could get confusing. Especially since the connection id semantics change when dealing with client. There is an existing Derby entry Derby-293 to correlate the client and server connections. Might it be good to defer the client part of this work until that is considered? 2) I think it would be good to document the connection id semantics in the Jira entry and the code. connection toString should uniquely identify the connection --- Key: DERBY-243 URL: http://issues.apache.org/jira/browse/DERBY-243 Project: Derby Type: Improvement Components: JDBC Reporter: Kathey Marsden Assignee: David Van Couvering Priority: Trivial Fix For: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.0.0 Attachments: DERBY-243.diff The toString() on the Derby connection doesn't print unique information. for example System.out.println(conn) prints: EmbedConnection in the case of derby embedded It would be great if the toString() method for connections could be used to differentiate one connection from another. -- 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-265) In Network Server retrieving BLOB values with autocommit off causes NullPointerException in INSANE build / AssertFailure in in BaseContainerHandle.getTransaction in SANE Build
[ http://issues.apache.org/jira/browse/DERBY-265?page=all ]
Sunitha Kambhampati reassigned DERBY-265:
-
Assign To: Sunitha Kambhampati
In Network Server retrieving BLOB values with autocommit off causes
NullPointerException in INSANE build / AssertFailure in in
BaseContainerHandle.getTransaction in SANE Build
---
Key: DERBY-265
URL: http://issues.apache.org/jira/browse/DERBY-265
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.0.0
Reporter: Kathey Marsden
Assignee: Sunitha Kambhampati
Fix For: 10.1.0.0
Attachments: MsgNpe.java, MsgNpe2.java
problem when retreiving rows with BLOB
values with network server with autocommit on. The workaround
was to turn autocommit off. The Problem manifested itself with
this trace but there was an underlying NPE in the
derby.log
java.lang.NullPointerException
at com.ibm.db2.jcc.c.md.a(md.java:289)
at
com.ibm.db2.jcc.c.SqlException.getMessage(SqlException.java:194)
at
java.lang.Throwable.getLocalizedMessage(Throwable.java:266)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2131)
at java.io.PrintStream.print(PrintStream.java:462)
at java.io.PrintStream.println(PrintStream.java:599)
at java.lang.Throwable.printStackTrace(Throwable.java:461)
at java.lang.Throwable.printStackTrace(Throwable.java:451)
at temp.CloudscapeTest.init(CloudscapeTest.java:28)
at temp.CloudscapeTest.main(CloudscapeTest.java:92)
When run with a SANE Build with the attached repro, the
derby.log shows this trace.
}), Committing
2005-02-08 21:19:45.626 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Executing prepared
statement: SELECT MAP_ID, MAP_NAME, REGION, AREA,
PHOTO_FORMAT, PICTURE FROM MAPS :End prepared statement
2005-02-08 21:19:45.686 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Executing prepared
statement: SELECT MAP_ID, MAP_NAME, REGION, AREA,
PHOTO_FORMAT, PICTURE FROM MAPS :End prepared statement
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Committing
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Cleanup action starting
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Failed Statement is:
null
org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT
FAILED
at
org.apache.derby.iapi.services.sanity.SanityManager.ASSERT(Sanit
yManager.java:99)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.getTran
saction(BaseContainerHandle.java:830)
at
org.apache.derby.impl.store.raw.data.OverflowInputStream.initStr
eam(OverflowInputStream.java:158)
at
org.apache.derby.iapi.services.io.FormatIdInputStream.initStream
(FormatIdInputStream.java:226)
at
org.apache.derby.impl.jdbc.EmbedBlob.init(EmbedBlob.java:12
8)
at
org.apache.derby.impl.jdbc.EmbedResultSet20.getBlob(EmbedResultS
et20.java:1552)
at
org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnTh
read.java:5871)
at
org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnTh
read.java:5754)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDACo
nnThread.java:595)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.jav
a:226)
It seems that network server is somehow closing the resultset
or committing too early. This problem may be related to DERBY-213
There seem to be some scenario in which Store throws this
ASSERTION instead of the proper user error if the blob is
accessed outside of the transaction, but we don't have a repro
outside of network server right now.
This occurred with JCC 2.4. I have not tried it with derby client
--
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-265) In Network Server retrieving BLOB values with autocommit off causes NullPointerException in INSANE build / AssertFailure in in BaseContainerHandle.getTransaction in SANE Build
[ http://issues.apache.org/jira/browse/DERBY-265?page=all ]
Sunitha Kambhampati updated DERBY-265:
--
Attachment: MsgNpe2.java
MsgNpe does not have schema details etc. So attaching MsgNpe2.java - a
modified version of MsgNpe, which reproduces the problem mentioned in this bug.
In Network Server retrieving BLOB values with autocommit off causes
NullPointerException in INSANE build / AssertFailure in in
BaseContainerHandle.getTransaction in SANE Build
---
Key: DERBY-265
URL: http://issues.apache.org/jira/browse/DERBY-265
Project: Derby
Type: Bug
Components: Network Server
Versions: 10.1.0.0
Reporter: Kathey Marsden
Assignee: Sunitha Kambhampati
Fix For: 10.1.0.0
Attachments: MsgNpe.java, MsgNpe2.java
problem when retreiving rows with BLOB
values with network server with autocommit on. The workaround
was to turn autocommit off. The Problem manifested itself with
this trace but there was an underlying NPE in the
derby.log
java.lang.NullPointerException
at com.ibm.db2.jcc.c.md.a(md.java:289)
at
com.ibm.db2.jcc.c.SqlException.getMessage(SqlException.java:194)
at
java.lang.Throwable.getLocalizedMessage(Throwable.java:266)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2131)
at java.io.PrintStream.print(PrintStream.java:462)
at java.io.PrintStream.println(PrintStream.java:599)
at java.lang.Throwable.printStackTrace(Throwable.java:461)
at java.lang.Throwable.printStackTrace(Throwable.java:451)
at temp.CloudscapeTest.init(CloudscapeTest.java:28)
at temp.CloudscapeTest.main(CloudscapeTest.java:92)
When run with a SANE Build with the attached repro, the
derby.log shows this trace.
}), Committing
2005-02-08 21:19:45.626 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Executing prepared
statement: SELECT MAP_ID, MAP_NAME, REGION, AREA,
PHOTO_FORMAT, PICTURE FROM MAPS :End prepared statement
2005-02-08 21:19:45.686 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Executing prepared
statement: SELECT MAP_ID, MAP_NAME, REGION, AREA,
PHOTO_FORMAT, PICTURE FROM MAPS :End prepared statement
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Committing
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Cleanup action starting
2005-02-08 21:19:45.726 GMT Thread[DRDAConnThread_2,5,main]
(XID = 2845), (SESSIONID = 1), (DATABASE = toursDB), (DRDAID =
NF01.G838-866941820371235014{10}), Failed Statement is:
null
org.apache.derby.iapi.services.sanity.AssertFailure: ASSERT
FAILED
at
org.apache.derby.iapi.services.sanity.SanityManager.ASSERT(Sanit
yManager.java:99)
at
org.apache.derby.impl.store.raw.data.BaseContainerHandle.getTran
saction(BaseContainerHandle.java:830)
at
org.apache.derby.impl.store.raw.data.OverflowInputStream.initStr
eam(OverflowInputStream.java:158)
at
org.apache.derby.iapi.services.io.FormatIdInputStream.initStream
(FormatIdInputStream.java:226)
at
org.apache.derby.impl.jdbc.EmbedBlob.init(EmbedBlob.java:12
8)
at
org.apache.derby.impl.jdbc.EmbedResultSet20.getBlob(EmbedResultS
et20.java:1552)
at
org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnTh
read.java:5871)
at
org.apache.derby.impl.drda.DRDAConnThread.writeQRYDTA(DRDAConnTh
read.java:5754)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDACo
nnThread.java:595)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.jav
a:226)
It seems that network server is somehow closing the resultset
or committing too early. This problem may be related to DERBY-213
There seem to be some scenario in which Store throws this
ASSERTION instead of the proper user error if the blob is
accessed outside of the transaction, but we don't have a repro
outside of network server right now.
This occurred with JCC 2.4. I have not tried it with derby client
--
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-285) Network Client should not print non-ascii token separators in message when it cannot connect to the server to retrieve the error message
[ http://issues.apache.org/jira/browse/DERBY-285?page=all ] Kathey Marsden reassigned DERBY-285: Assign To: Kathey Marsden Network Client should not print non-ascii token separators in message when it cannot connect to the server to retrieve the error message Key: DERBY-285 URL: http://issues.apache.org/jira/browse/DERBY-285 Project: Derby Type: Improvement Components: Network Client Versions: 10.1.0.0 Reporter: Kathey Marsden Assignee: Kathey Marsden If Network Client cannot connect to the database to retrieve an error message, it will print only the message tokens, the non-ascii token separators, and derby log location. It would be good if at least the message could be formatted to present a better message to the user without the non-ascii characters. To reproduce try a database shutdown. Because the database is shutdown, the client cannot retrieve the actual message from the server. It therefore just prints the tokens. Start network server java org.apache.derby.drda.NetworkServerControl start $ java org.apache.derby.tools.ij ij version 10.1 ij connect 'jdbc:derby://localhost:1527/wombat;create=true'; ij connect 'jdbc:derby://localhost:1527/wombat;shutdown=true'; ERROR 08006: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: wombat[]08006.D[]Database 'wombat' shutdown.[](server log:derby.log) ij Note: The actual offending characters have been replaced in the output in this bug by []. This is because they break Jira XML retrieval! -- 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-300) Creation of SQLWarning on a getConnection causes hang on 131 vms when server and client are in same vm.
[ http://issues.apache.org/jira/browse/DERBY-300?page=all ] Sunitha Kambhampati updated DERBY-300: -- Attachment: testNS.java Repro for the hang. To run java testNS Creation of SQLWarning on a getConnection causes hang on 131 vms when server and client are in same vm. --- Key: DERBY-300 URL: http://issues.apache.org/jira/browse/DERBY-300 Project: Derby Type: Bug Components: JDBC Versions: 10.1.0.0 Environment: seems to occur on 131 vms, hang seen on both sun 1.3.1 and ibm 1.3.1 Reporter: Sunitha Kambhampati Priority: Trivial Attachments: testNS.java Problem - with 131 vms, if server and client are in the same jvm, on a second get connection with create=true attribute in the url, there is a hang. Basically, -- the first getConnection works ok -- but on the second getConnection, a SQLWarning needs to be generated to say that the database already exists and in this scenario, it seems like at the point where it is creating a SQLWarning , there is a deadlock. The call to SQLWarning constructor does not return. On doing a java core dump , the thread in question seems to be in a wait state (conditional wait). Guess is it has to do with the driver manager lock Also note, this problem is observed only with 131 vms, so I guess it was fixed in the later vms (1.4.1, 1.4.2 1.5) Opened this entry to keep track of this. -- 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] change to derbynet/testSecMec.java test to fix failure on 131 vms.
David Van Couvering wrote: Hi, Sunitha This patch looks good, I successfully built and ran derbynetmats in my environment with JDK14 and JDK13. I agree we definitely need to log a bug that the system hangs if you accidentally use create=true when the DB is already created -- this seems like a very possible thing to happen and I suspect many folks are still on JDK13. Thanks for reviewing it. I have opened a jira bug ( Derby-300) to keep track of this issue. Sunitha.
