date:20060622


David Van Couvering wrote:




Rick Hillegas wrote:


Hi David,

I had a couple more comments on the compatibility commitments. 
Cheers-Rick


 - Changes to stored procedures: We will have to change column order if
  we add Derby-specific columns to a metadata ResultSet and then a later
  JDBC also adds more columns.



See Lance's email; OK to leave as is?


I thought the gist of Lance's response was this: It's ok to add 
vendor-specific columns to metadata ResultSets. However, the leading 
columns of the ResultSet must be the columns described in the JDBC spec 
and those columns must appear in the specified order. After that the 
order of vendor-specific columns doesn't matter. However, the names of 
those vendor-specific columns do matter; those names are the stable 
interface. I don't think the existing text on the compatibility webpage 
captures this.






 - Changes to Database Tables: We should be allowed to drop indexes
  on System tables.



OK



 - Changes to Command Line Interfaces. I don't understand why error
   message text can't be changed. This contradicts what is said
   in the Interface Table below.



Hm, good point.  I suppose changing the error message text *is* an 
incompatible change, but given that the interface is private, it's OK 
to do it.  But it is a confusing message.  Any suggestions?  I can


(a) remove error message text from the list of incompatible changes
(b) keep it, but clarify that this is a private interface
(c) make error message text a public interface

My vote is for (a).  Anyone disagree?


That's my vote too, thanks.






 - Other miscellaneous formats. I'm not clear on what these miscellaneou
  files and strings are. For example, I'd like to make sure that 
we're not enshrining

  the current RUNTIMESTATISTICS output.



Again, I think this goes back to the same point.  It's not clear what 
the relationship is to the classification of an interface in the 
interfaces table and what it means to make an incompatible change.


I think you're assuming incompatible changes can only apply to public 
interfaces, because it's really kind of moot/inapplicable for private 
interfaces.


I think there's value in describing what it means to make an 
incompatible interface change, but I think the ultimate truth in 
terms of what we actually support in terms of interface stability 
across releases is described in the interfaces table.   I think some 
text in the incompatible changes section clarifying this would be 
helpful.


Any thoughts?


I can see that Private Stable applies to the client/server api. These 
apis should remain forward/backward compatible within a release family. 
Do Private Stable interfaces turn up in other situations?







 - Interface table:

   o Shouldn't the public client api be stable like the embedded api?



Yes



   o What is meant by Defaults returned by DatabaseMetadata
   methods?



I don't know, I think I put this in as feedback from someone else.  
Can anyone clarify?



   o I think that the format of RUNTIMESTATISTICS output is unstable.



OK, anyone disagree?

Thanks for your review, Rick!

David



David Van Couvering wrote:

Hi, all.  I am thinking of setting up two separate votes based on 
the Wiki page at


http://wiki.apache.org/db-derby/ForwardCompatibility

The first one would be on our overall model/approach to making 
compatibility commitments, as described in the Wiki page.


The second would be specifically for the interface table, targetted 
at the 10.2 release.


The reason for separating these out is because, for each release, we 
should update the interface table and have a new vote; the overall 
model/approach does not need to be updated or voted on for each 
release.


I would copy the appropriate text directly into the email for the 
vote, so that the thing we're voting on is a frozen snapshot, not a 
live document like the Wiki page.


I'd like your feedback on this approach.  I'd also like to make sure 
there aren't any lingering issues with the Wiki page as it stands, 
before I go through the process of running a vote.


Thanks,

David

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Thanks, Jean. The Edition line turns up in the visible text which 
appears in the printed document. That makes me think that it applies to 
something that the customer, the reader, cares about. I don't think the 
reader is particularly concerned about our transition to dita. If that 
is what Edition is supposed to capture, perhaps the Edition lines should 
be moved to a comments section so that they will not be 
visible/confusing to customers.


Regards,
-Rick

Jean T. Anderson wrote:


Rick Hillegas (JIRA) wrote:
 


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

Rick Hillegas updated DERBY-1271:
-

   Attachment: derby-1271_copyrights.diff

Attaching derby-1271_copyrights.diff. This adjusts dates in the visible 
copyright notices in the user guides. Touches the following files:

   



The update of the copyright line looks fine to me, but I'm not so sure
about the change of the Second Edition (July 2005) line to Third
Edition (July 2006).

I don't know the Edition history -- suspect it maps to the conversion
of the source docs to DITA. Does anyone know for sure?

-jean

[jira] Updated: (DERBY-1361) positioned updates and deletes allowed after a commit without repositioning the cursor - if the table is indexed on the columns selected

2006-06-22 Thread Andreas Korneliussen (JIRA)

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

Andreas Korneliussen updated DERBY-1361:


Attachment: DERBY-1361v2.diff
DERBY-1361v2.stat

Attaching an updated patch. Two more master files had to be updated because of 
the error code change. With this latest patch, I have run derbyall with no 
failures.
I will until next week days before I commit this patch, in case anyone would 
like to give some review comments.

 positioned updates and deletes allowed after a commit without repositioning 
 the cursor - if the table is indexed on the columns selected
 

  Key: DERBY-1361
  URL: http://issues.apache.org/jira/browse/DERBY-1361
  Project: Derby
 Type: Bug

   Components: JDBC
 Versions: 10.2.0.0
  Environment: Java 1.4
 Reporter: Andreas Korneliussen
 Assignee: Andreas Korneliussen
  Attachments: DERBY-1361.diff, DERBY-1361.stat, DERBY-1361v2.diff, 
 DERBY-1361v2.stat

 After a commit, the cursor should be positioned before the next row (not on a 
 row). However in Derby 10.2, I now see the following behavior if the table 
 has an index on the selected columns:
 ij create table t (id int primary key);
 ij commit;
 ij insert into t values 1,2,3,4,5,6,7,8,9;
 9 rows inserted/updated/deleted
 ij commit;
 ij get cursor c1 as 'select * from t for update';
 ij next c1;
 ID 
 ---
 1  
 ij commit;
 ij update t set id=id+1000 where current of c1;
 1 row inserted/updated/deleted
 ij commit;
 ij update t set id=id+1000 where current of c1;
 1 row inserted/updated/deleted
 ij 
 The expected behavior is  that the UPDATE .. WHERE CURRENT OF fails with:
 ERROR 24000: Invalid cursor state - no current row.
 The problem applies to both scrollable and forward-only updatable cursors.
 Note: If the table is created *without* the index, I do see the expected 
 behavior.
 I am marking this as a regression, since this issue is not reproducible on 
 older, released versions of derby (I have tested with 10.1.2.1).

-- 
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: Tuncation of trailing blanks and lengthless streaming overloads

Kristian Waagan wrote:

 Hello,
 
 I'm working on DERBY-1417; adding new lengthless overloads to the
 streaming API.  So far, I have only been looking at implementing this in
 the embedded driver. Based on some comments in the code, I have a few
 questions and observations regarding truncation of trailing blanks in
 the various character data types.
 
 TypeTrail. blank trunc. Where
 
 CHARallowed SQLChar.normalize
 VARCHAR allowed SQLVarchar.normalize
 LONG VARCHAR   disallowed   SQLLongVarchar.normalize
 CLOBallowed streaming or
 SQLVarchar.normalize, depending
 on source.
 
 As can be seen, only data for CLOB is truncated for trailing blanks in
 the streaming class. We must still read all the data, or so much as we
 need to know the insertion will fail, but we don't have to store it all
 in memory.
 
 Truncation of trailing blanks is not allowed at all for LONG VARCHAR
 (according to code comments and bug 5592 - haven't found the place this
 is stated in the specs).
 
 My question is, should we do the truncate check for CHAR and VARCHAR on
 the streaming level as well?
 If we don't add this feature, inserting a
 10GB file into a VARCHAR field by mistake will cause 10GB to be loaded
 into memory even though the max size allowed is ~32K, possibly causing
 out-of-memory errors. The error could be generated at an earlier stage
 (possibly after reading ~32K +1 bytes).

I would say its a separate issue to the one you are addressing.
Applications most likely won't be inserting 10Gb values into
CHAR/VARCHAR columns using streams as it's not going to work.
Maybe enter a bug, but doesn't seem it has to be fixed as part of this
issue.

 As far as I can tell, adding this feature is a matter of modifying the
 'ReaderToUTF8' class and the
 'EmbedPrearedStatement.setCharacterStreamInternal' method.
 One could also optimize the reading of data into LONG VARCHAR, where one
 would abort the reading as soon as you can instead of taking it all into
 memory first. This would require some special case handling in the
 mentioned locations.
 
 
 Another matter is that streams will not be checked for exact length
 match when using the lengthless overloads, as we don't have a specified
 length to compare against.
 I have a preliminary implementation for setAsciiStream,
 setCharacterStream  and setClob (all without length specifications) in
 EmbedPreparedStatement.

What's the issue with setClob()? The current method doesn't take a
length. Has java.sql.Clob been changed to not always have a length?

Dan.

Re: ADVICE REQUESTED: Fixing MessageBundleTest


Hi David,

You might want to wrap the test in a custom Ant Task. These are 
described in the Ant manual: Developing with Ant-Writing Your Own 
Task. You can then check the return status of the task and fail the 
build if appropriate.


Regards,
-Rick

David Van Couvering wrote:

Hm, a build-time check.  I guess in a way it is a build-time issue.  
Let me think about how I might do that, thanks for the idea.


David

Daniel John Debrunner wrote:


David Van Couvering wrote:


So, as Andrew very astutely pointed out, i18n/MessageBundleTest.java
will not succeed when running against the jar files because it tries to
load shared/common/reference/SQLState, which is not included in the jar
files.  This problem also exists for MessageId.java, which this test
also refers to and which also is not included in the jar files.



Does this need to be a test, could it be converted into a build time
check? Then there are no requirements for these classes to be in
derbytesting.jar. Also there is probably no requirement to run this test
on different platforms.

I used to have something similar (pre-open source), that found messages
that existed but were never used.

Dan.

[jira] Updated: (DERBY-1313) SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED warnings.

2006-06-22 Thread Fernanda Pizzorno (JIRA)

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

Fernanda Pizzorno updated DERBY-1313:
-

Attachment: derby-1313v1.pdf

The attached document (derby-1313v1.pdf) contains a short description of the 
work done in DERBY-1313 and DERBY-1374, and some thoughts of what is needed in 
order to extend this work to cover other warnings and exception.

 SUR: Use DRDA's extended diagnostic to send ROW_UPDATED and ROW_DELETED 
 warnings.
 -

  Key: DERBY-1313
  URL: http://issues.apache.org/jira/browse/DERBY-1313
  Project: Derby
 Type: Bug

   Components: JDBC
 Reporter: Fernanda Pizzorno
 Assignee: Fernanda Pizzorno
  Attachments: derby-1313.diff, derby-1313.stat, derby-1313v1.pdf, 
 derby-1313v2.diff, derby-1313v2.stat, derby-1313v3.diff, derby-1313v3.stat

 Detectability of own changes is implemented in the client using warnings cf 
 the write-up for DERBY-775. When a row has been deleted and/or updated, a 
 warning will be sent to the client to indicate that fact. Presently, only one 
 warning can be sent each time a data row is sent from to the client, that 
 means that some warnings may be lost. Using extended diagnostic allows us to 
 send several warnings for each data row.
 I propose to use extended diagnostics to send ROW_UPDATED and ROW_DELETED 
 warnings when necessary. This may later be extended for other warnings, but I 
 do not plan to do it as a part of the work in this issue.

-- 
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-1395) Change the client SQLState to match that of embedded for the exception thrown on a closed statement whose connection is also closed

2006-06-22 Thread Deepa Remesh (JIRA)

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

Deepa Remesh commented on DERBY-1395:
-

I had seen the first scenario (both connection and statement closed) in 
jdbcapi/checkDataSource.java.This is in the checkConnection method. The 
scenario Knut mentions is covered in ClosedObjectTest.java.

 Change the client SQLState to match that of embedded for the exception thrown 
 on a closed statement whose connection is also closed
 ---

  Key: DERBY-1395
  URL: http://issues.apache.org/jira/browse/DERBY-1395
  Project: Derby
 Type: Improvement

   Components: Network Client
 Versions: 10.2.0.0, 10.1.3.0
 Reporter: Deepa Remesh
 Assignee: David Van Couvering
 Priority: Trivial


 Scenario: Both connection and statement are closed and an operation is 
 performed on a closed statement. SQLStates are as follows:
 Embedded: SQLSTATE: XJ012, Message: Statement Closed
 Client before DERBY-843 fix: SQLSTATE = null, message = Statement closed
 Client after DERBY-843 fix: SQLSTATE: 08003, Message: connection closed
 This issue is related to the effort started in DERBY-254.

-- 
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-955) Get derbyall on jdk1.6

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

Olav Sandstaa updated DERBY-955:


Attachment: bug955_derbyall.diff

This patch contains fixes to the following tests that are failing when
running derbyall with jdk 1.6:

* derbynetclientmats: tools/ieptests.sql 

  -updated master file for jdk16

* derbynetclientmats: jdbcapi/parameterMappint.java

  -REMOVED jdk16 specific master file

* derbynetclientmats: jdbcapi/checkDataSource30.java

  -updated checkDataSource30.java and checkDataSource.java to produce
   output that is the same when running with jdk15 and jdk16
  -updated master files to reflect changes in output

* derbynetmats: tools/ieptests.sql

  -updated master file for jdk16


svn status reports:

M  
java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource30.java
M  
java/testing/org/apache/derbyTesting/functionTests/tests/jdbcapi/checkDataSource.java
M  
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNet/jdk16/ieptests.out
M  
java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource30.out
D  
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/parameterMapping.out
M  
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/jdk16/ieptests.out
M  
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource.out
M  
java/testing/org/apache/derbyTesting/functionTests/master/DerbyNetClient/checkDataSource30.out
M  
java/testing/org/apache/derbyTesting/functionTests/master/checkDataSource.out


Note: one master file has been removed.

I have run derbyall with jdk 1.5 and 1.6.

The patch is ready for review and commit.


 Get derbyall on jdk1.6
 --

  Key: DERBY-955
  URL: http://issues.apache.org/jira/browse/DERBY-955
  Project: Derby
 Type: Bug

   Components: Test
 Versions: 10.2.0.0
 Reporter: Rick Hillegas
 Assignee: Anurag Shekhar
  Fix For: 10.2.0.0
  Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, 
 bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, 
 bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff

 This bug is a placeholder for patches which enable derbyall to run on jdk1.6.

-- 
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-955) Get derbyall on jdk1.6

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

Olav Sandstaa updated DERBY-955:


Derby Info: [Patch Available]

 Get derbyall on jdk1.6
 --

  Key: DERBY-955
  URL: http://issues.apache.org/jira/browse/DERBY-955
  Project: Derby
 Type: Bug

   Components: Test
 Versions: 10.2.0.0
 Reporter: Rick Hillegas
 Assignee: Anurag Shekhar
  Fix For: 10.2.0.0
  Attachments: bug955_blobclob4BLOB.diff, bug955_derbyall.diff, 
 bug955_sed2.diff, bug955_sed_SQLException.diff, bug955_sysinfo.diff, 
 bug955_wireUpJDBC4ClientSuite.diff, bug955_wireUpJDBC4Suite.diff

 This bug is a placeholder for patches which enable derbyall to run on jdk1.6.

-- 
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-1271) Release documentation for JDBC4 release

Rick Hillegas wrote:
 Thanks, Jean. The Edition line turns up in the visible text which
 appears in the printed document. That makes me think that it applies to
 something that the customer, the reader, cares about. I don't think the
 reader is particularly concerned about our transition to dita. If that
 is what Edition is supposed to capture, perhaps the Edition lines should
 be moved to a comments section so that they will not be
 visible/confusing to customers.

The Developers Guide has a first edition for both 10.0 and 10.1:
   http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html
   http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html

I don't know why the Edition was bumped for the others. :-)

If there isn't a major change to the content of the book, I don't think
the edition should be bumped.

Working With Derby should definitely not be bumped from First to
Second edition since 10.2 will be its first release.

 -jean

[jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

2006-06-22 Thread Deepa Remesh (JIRA)

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

Deepa Remesh commented on DERBY-1435:
-

Thanks for looking into this Suresh. Now, I can see this from the traces too. 
We are re-using the prepared statement after table t1 is dropped. Here are the 
stack traces from ij for execution of a new statement (insert into t2 
values(2)) and a previously executed statement (insert into t2 values(1)) after 
table t1 is dropped:

ij --- these inserts should not work, but the second insert gives XSAI2
insert into t2 values(2);
ERROR 42X05: Table/View 'T1' does not exist.
ERROR 42X05: Table/View 'T1' does not exist.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304)
at 
org.apache.derby.impl.sql.compile.DMLModStatementNode.verifyTargetTable(DMLModStatementNo
de.java:230)
at 
org.apache.derby.impl.sql.compile.InsertNode.bind(InsertNode.java:248)
at 
org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:344)
at 
org.apache.derby.impl.sql.GenericStatement.prepareStorable(GenericStatement.java:591)
at 
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.compileStatement(SPSDescriptor.java:35
3)
at 
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:2
83)
at 
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.prepareAndRelease(SPSDescriptor.java:3
03)
at 
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav
a:690)
at 
org.apache.derby.iapi.sql.dictionary.SPSDescriptor.getPreparedStatement(SPSDescriptor.jav
a:651)
at 
org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto
r.java:138)
at 
org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:
110)
at 
org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator
.java:277)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(InsertResultSet.java:1
134)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.open(InsertResultSet.java:522)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
361)
at 
org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1181)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:584)
at 
org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:516)
at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
at org.apache.derby.impl.tools.ij.Main.go(Main.java:207)
at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:173)
at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
at org.apache.derby.tools.ij.main(ij.java:60)
ij insert into t2 values(1);
ERROR XSAI2: The conglomerate (896) requested does not exist.
ERROR XSAI2: The conglomerate (896) requested does not exist.
at 
org.apache.derby.iapi.error.StandardException.newException(StandardException.java:304)
at 
org.apache.derby.impl.store.access.heap.HeapConglomerateFactory.readConglomerate(HeapCong
lomerateFactory.java:224)
at 
org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.jav
a:484)
at 
org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction
.java:389)
at 
org.apache.derby.impl.store.access.RAMTransaction.getDynamicCompiledConglomInfo(RAMTransa
ction.java:701)
at 
org.apache.derby.impl.sql.execute.DMLWriteResultSet.init(DMLWriteResultSet.java:82)
at 
org.apache.derby.impl.sql.execute.DMLWriteResultSet.init(DMLWriteResultSet.java:66)
at 
org.apache.derby.impl.sql.execute.InsertResultSet.init(InsertResultSet.java:343)
at 
org.apache.derby.impl.sql.execute.GenericResultSetFactory.getInsertResultSet(GenericResul
tSetFactory.java:95)
at 
org.apache.derby.exe.ac46a08075x010bxfc52x1188x001171d80.fillResultSet(Unknown
 Source
)
at 
org.apache.derby.exe.ac46a08075x010bxfc52x1188x001171d80.execute(Unknown 
Source)
at 
org.apache.derby.impl.sql.GenericActivationHolder.execute(GenericActivationHolder.java:32
6)
at 
org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:
359)
at 
org.apache.derby.impl.sql.execute.GenericTriggerExecutor.executeSPS(GenericTriggerExecuto
r.java:169)
at 
org.apache.derby.impl.sql.execute.RowTriggerExecutor.fireTrigger(RowTriggerExecutor.java:
110)
at 
org.apache.derby.impl.sql.execute.TriggerEventActivator.notifyEvent(TriggerEventActivator
.java:277)
at

Re: [jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

2006-06-22 Thread Deepa Remesh


On 6/22/06, Øystein Grøvlen (JIRA) derby-dev@db.apache.org wrote:


I have sometimes seen the same error message in another context.  See 
DERBY-637. No triggers involved in my case and not easily reproduced (but I 
have seen it several times).  I had to shutdown and restart the database to 
make the error disappers.


I took a quick look at DERBY-637 to see if there is anything similar
to the scenario in DERBY-1435. I am new to these areas but I think it
will be good if we have a repro. Someone more familiar may be able to
deduct something. If you still have the repro, it would be helpful if
you can post it.

Thanks,
Deepa

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release


Jean T. Anderson wrote:


Rick Hillegas wrote:
 


Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned about our transition to dita. If that
is what Edition is supposed to capture, perhaps the Edition lines should
be moved to a comments section so that they will not be
visible/confusing to customers.
   



The Developers Guide has a first edition for both 10.0 and 10.1:
  http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html
  http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html

I don't know why the Edition was bumped for the others. :-)

If there isn't a major change to the content of the book, I don't think
the edition should be bumped.

Working With Derby should definitely not be bumped from First to
Second edition since 10.2 will be its first release.
 

I could just bump the edition for the Reference Guide, which will carry 
a lot of edits to reflect JDBC4. Would that be acceptable?



-jean

[jira] Created: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver

Text written by SQLException.toString differs between client and embedded driver


 Key: DERBY-1438
 URL: http://issues.apache.org/jira/browse/DERBY-1438
 Project: Derby
Type: Improvement

  Components: JDBC, Newcomer  
Versions: 10.2.0.0
 Environment: Sun JDK 1.5
Reporter: Olav Sandstaa
Priority: Trivial


The first part of the string written by SQLExeption.toString() differs
between the Derby client driver and the embedded driver. The embedded
driver writes:

   SQL Exception: Table/View 'DERBYDB' does not exist.

while the client driver writes:

   java.sql.SQLException: Table/View 'DERBYDB' does not exist.

It would be good if we changed this so the same text is written by
both drivers. This reduces the difference seen when changing between
client and embedded Derby and it make it possible to reduce the amount
of sed-ing or the number of master file variants for some tests.


-- 
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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table




Rick Hillegas wrote:

David Van Couvering wrote:




Rick Hillegas wrote:


Hi David,

I had a couple more comments on the compatibility commitments. 
Cheers-Rick


 - Changes to stored procedures: We will have to change column order if
  we add Derby-specific columns to a metadata ResultSet and then a later
  JDBC also adds more columns.



See Lance's email; OK to leave as is?


I thought the gist of Lance's response was this: It's ok to add 
vendor-specific columns to metadata ResultSets. However, the leading 
columns of the ResultSet must be the columns described in the JDBC spec 
and those columns must appear in the specified order. After that the 
order of vendor-specific columns doesn't matter. However, the names of 
those vendor-specific columns do matter; those names are the stable 
interface. I don't think the existing text on the compatibility webpage 
captures this.


OK, I'll work on that







 - Changes to Database Tables: We should be allowed to drop indexes
  on System tables.



OK



 - Changes to Command Line Interfaces. I don't understand why error
   message text can't be changed. This contradicts what is said
   in the Interface Table below.



Hm, good point.  I suppose changing the error message text *is* an 
incompatible change, but given that the interface is private, it's OK 
to do it.  But it is a confusing message.  Any suggestions?  I can


(a) remove error message text from the list of incompatible changes
(b) keep it, but clarify that this is a private interface
(c) make error message text a public interface

My vote is for (a).  Anyone disagree?


That's my vote too, thanks.



OK






 - Other miscellaneous formats. I'm not clear on what these miscellaneou
  files and strings are. For example, I'd like to make sure that 
we're not enshrining

  the current RUNTIMESTATISTICS output.



Again, I think this goes back to the same point.  It's not clear what 
the relationship is to the classification of an interface in the 
interfaces table and what it means to make an incompatible change.


I think you're assuming incompatible changes can only apply to public 
interfaces, because it's really kind of moot/inapplicable for private 
interfaces.


I think there's value in describing what it means to make an 
incompatible interface change, but I think the ultimate truth in 
terms of what we actually support in terms of interface stability 
across releases is described in the interfaces table.   I think some 
text in the incompatible changes section clarifying this would be 
helpful.


Any thoughts?


I can see that Private Stable applies to the client/server api. These 
apis should remain forward/backward compatible within a release family. 
Do Private Stable interfaces turn up in other situations?


Yes, that's right.  I wonder if the database file format is also Private 
Stable.  I am still looking for some guidance in that area in terms of 
what are incompatible changes...


David








 - Interface table:

   o Shouldn't the public client api be stable like the embedded api?



Yes



   o What is meant by Defaults returned by DatabaseMetadata
   methods?



I don't know, I think I put this in as feedback from someone else.  
Can anyone clarify?



   o I think that the format of RUNTIMESTATISTICS output is unstable.



OK, anyone disagree?

Thanks for your review, Rick!

David



David Van Couvering wrote:

Hi, all.  I am thinking of setting up two separate votes based on 
the Wiki page at


http://wiki.apache.org/db-derby/ForwardCompatibility

The first one would be on our overall model/approach to making 
compatibility commitments, as described in the Wiki page.


The second would be specifically for the interface table, targetted 
at the 10.2 release.


The reason for separating these out is because, for each release, we 
should update the interface table and have a new vote; the overall 
model/approach does not need to be updated or voted on for each 
release.


I would copy the appropriate text directly into the email for the 
vote, so that the thing we're voting on is a frozen snapshot, not a 
live document like the Wiki page.


I'd like your feedback on this approach.  I'd also like to make sure 
there aren't any lingering issues with the Wiki page as it stands, 
before I go through the process of running a vote.


Thanks,

David

Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table

Knut Anders Hatlen wrote:

 Daniel John Debrunner [EMAIL PROTECTED] writes:
 
 
David Van Couvering wrote:

Good news Lance, thanks, I was getting worried if we were going to have
to regularly change column order and break existing applications/IDEs/etc.

Hopefully we don't have any documented Derby specific additional columns
in the metadata, that would be non-standard.
 
 
 The only non-standard columns we have are METHOD_ID and PARAMETER_ID
 in getProcedureColumns and getFunctionParameters. For
 getProcedureColumns, they are documented in the reference manual.

Yes they are documented, but not in any useful way. There is no
description of what they represent, only the text:

   a Derby-specific column.

I think METHOD_ID could be removed, it's an artifact of the old way
Cloudscape used to support non-standard method aliases.

Dan.

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Rick Hillegas wrote:

 Jean T. Anderson wrote:
 
 Rick Hillegas wrote:
  

 Thanks, Jean. The Edition line turns up in the visible text which
 appears in the printed document. That makes me think that it applies to
 something that the customer, the reader, cares about. I don't think the
 reader is particularly concerned about our transition to dita. If that
 is what Edition is supposed to capture, perhaps the Edition lines should
 be moved to a comments section so that they will not be
 visible/confusing to customers.
   


 The Developers Guide has a first edition for both 10.0 and 10.1:
   http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html
   http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html

 I don't know why the Edition was bumped for the others. :-)

 If there isn't a major change to the content of the book, I don't think
 the edition should be bumped.

 Working With Derby should definitely not be bumped from First to
 Second edition since 10.2 will be its first release.
  

 I could just bump the edition for the Reference Guide, which will carry
 a lot of edits to reflect JDBC4. Would that be acceptable?

What does the edition represent? Would this mean the first release of
the 10.2 documentation set would be partially at the second edition,
doesn't seem to make sense to me.

Dan.

[jira] Assigned: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver

2006-06-22 Thread David Van Couvering (JIRA)

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

David Van Couvering reassigned DERBY-1438:
--

Assign To: David Van Couvering

 Text written by SQLException.toString differs between client and embedded 
 driver
 

  Key: DERBY-1438
  URL: http://issues.apache.org/jira/browse/DERBY-1438
  Project: Derby
 Type: Improvement

   Components: JDBC, Newcomer
 Versions: 10.2.0.0
  Environment: Sun JDK 1.5
 Reporter: Olav Sandstaa
 Assignee: David Van Couvering
 Priority: Trivial


 The first part of the string written by SQLExeption.toString() differs
 between the Derby client driver and the embedded driver. The embedded
 driver writes:
SQL Exception: Table/View 'DERBYDB' does not exist.
 while the client driver writes:
java.sql.SQLException: Table/View 'DERBYDB' does not exist.
 It would be good if we changed this so the same text is written by
 both drivers. This reduces the difference seen when changing between
 client and embedded Derby and it make it possible to reduce the amount
 of sed-ing or the number of master file variants for some tests.

-- 
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-1438) Text written by SQLException.toString differs between client and embedded driver

2006-06-22 Thread David Van Couvering (JIRA)

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

David Van Couvering commented on DERBY-1438:


I'll take a look at this and see what I can do.  Thanks, Olav.

 Text written by SQLException.toString differs between client and embedded 
 driver
 

  Key: DERBY-1438
  URL: http://issues.apache.org/jira/browse/DERBY-1438
  Project: Derby
 Type: Improvement

   Components: JDBC, Newcomer
 Versions: 10.2.0.0
  Environment: Sun JDK 1.5
 Reporter: Olav Sandstaa
 Assignee: David Van Couvering
 Priority: Trivial


 The first part of the string written by SQLExeption.toString() differs
 between the Derby client driver and the embedded driver. The embedded
 driver writes:
SQL Exception: Table/View 'DERBYDB' does not exist.
 while the client driver writes:
java.sql.SQLException: Table/View 'DERBYDB' does not exist.
 It would be good if we changed this so the same text is written by
 both drivers. This reduces the difference seen when changing between
 client and embedded Derby and it make it possible to reduce the amount
 of sed-ing or the number of master file variants for some tests.

-- 
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-1271) Release documentation for JDBC4 release


Daniel John Debrunner wrote:


Rick Hillegas wrote:

 


Jean T. Anderson wrote:

   


Rick Hillegas wrote:


 


Thanks, Jean. The Edition line turns up in the visible text which
appears in the printed document. That makes me think that it applies to
something that the customer, the reader, cares about. I don't think the
reader is particularly concerned about our transition to dita. If that
is what Edition is supposed to capture, perhaps the Edition lines should
be moved to a comments section so that they will not be
visible/confusing to customers.
 
   


The Developers Guide has a first edition for both 10.0 and 10.1:
 http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html
 http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html

I don't know why the Edition was bumped for the others. :-)

If there isn't a major change to the content of the book, I don't think
the edition should be bumped.

Working With Derby should definitely not be bumped from First to
Second edition since 10.2 will be its first release.


 


I could just bump the edition for the Reference Guide, which will carry
a lot of edits to reflect JDBC4. Would that be acceptable?
   



What does the edition represent? Would this mean the first release of
the 10.2 documentation set would be partially at the second edition,
doesn't seem to make sense to me.

Dan.
 

This is what's troubling me too. From Jean's investigations it seems 
that edition doesn't have a consistent meaning across our user guides 
and releases. We could just remove the edition lines. If we leave them 
in, then it would be good to agree on their meaning. Maybe one of the 
following:


1) The Edition number is bumped whenever we create a release branch. We 
don't bump Edition for point or patch releases.


2) The Edition number is bumped whenever reviewers agree that a user 
guide has changed significantly.


3) The Edition number is the same as the release number. All user guides 
in a given release have identical Edition numbers.

[jira] Created: (DERBY-1440) ij running with client driver and jdk 1.6 omits chained exceptions in error messages

ij running with client driver and jdk 1.6 omits chained exceptions in error 
messages


 Key: DERBY-1440
 URL: http://issues.apache.org/jira/browse/DERBY-1440
 Project: Derby
Type: Bug

  Components: Tools, JDBC, Network Client  
Versions: 10.2.0.0
 Environment: Sun JDK 1.6
Reporter: Olav Sandstaa
Priority: Minor


When running some SQL queries through ij that fails it seems like some
information about chained exceptions is not presented to the user when
running with the client driver and jdk 1.6.


One example SQL that fails (taken from the ieptests.sql):
=

ij call SYSCS_UTIL.SYSCS_EXPORT_TABLE ('inventory', 'ORDERTABLE' ,
'extinout/order.dat', null, null, null) ;

When running this in ij the following error message is produced:



Java 1.6 Embedded driver:
=

ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.
ERROR 42Y07: Schema 'inventory' does not exist


Java 1.5 Client driver:
===

ERROR 38000: The exception 'SQL Exception: Schema 'inventory' does not
exist' was thrown while evaluating an expression. SQLSTATE: 42Y07:
Schema 'inventory' does not exist


Java 1.6 Client driver:
===

ERROR 38000: The exception 'java.sql.SQLSyntaxErrorException: Schema
'inventory' does not exist' was thrown while evaluating an expression.


The bug (or difference) here is that the client driver when running
with jdk 1.6 does not print the chained exception and SQL state.
It would be nice to have the same information in the output as what is
written by the embedded driver (or client driver running with jdk
1.5).



-- 
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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table

David Van Couvering wrote:

 
 
 Rick Hillegas wrote:


 I can see that Private Stable applies to the client/server api. These
 apis should remain forward/backward compatible within a release
 family. Do Private Stable interfaces turn up in other situations?
 
 
 Yes, that's right.  I wonder if the database file format is also Private
 Stable.  I am still looking for some guidance in that area in terms of
 what are incompatible changes...

What guidance do you need above:
http://db.apache.org/derby/papers/versionupgrade.html ?

(note there is a type in that document, at one point it has 'EM = 10',
I think that should be 'EM = 10'.)

I think that's the policy for on-disk format and did undergo a vote (I
believe).

Dan.

[jira] Commented: (DERBY-1438) Text written by SQLException.toString differs between client and embedded driver

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

Olav Sandstaa commented on DERBY-1438:
--

Personally, I prefer the text written by the embedded driver (SQL Exception:) 
over the text written by the client driver (java.sql.Exception:), but with 
the introduction of the SQL exception hierarchy in Java SE 6 it might be better 
to use the exact exception name (e.g. 
java.sql.IamSorryThisShouldNotHappenTodayException) which is what I think you 
get if you call SQLException.toString() and running with jdk 1.6.


 Text written by SQLException.toString differs between client and embedded 
 driver
 

  Key: DERBY-1438
  URL: http://issues.apache.org/jira/browse/DERBY-1438
  Project: Derby
 Type: Improvement

   Components: JDBC, Newcomer
 Versions: 10.2.0.0
  Environment: Sun JDK 1.5
 Reporter: Olav Sandstaa
 Assignee: David Van Couvering
 Priority: Trivial


 The first part of the string written by SQLExeption.toString() differs
 between the Derby client driver and the embedded driver. The embedded
 driver writes:
SQL Exception: Table/View 'DERBYDB' does not exist.
 while the client driver writes:
java.sql.SQLException: Table/View 'DERBYDB' does not exist.
 It would be good if we changed this so the same text is written by
 both drivers. This reduces the difference seen when changing between
 client and embedded Derby and it make it possible to reduce the amount
 of sed-ing or the number of master file variants for some tests.

-- 
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: [VOTE] 10.1.3.0 release

2006-06-22 Thread Rajesh Kartha


Kathey Marsden wrote:


Mike Matrigali wrote:


I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate.  While the bug
is an edge error case, the result is a corrupt db.  I believe
there is little risk as again the path is not one usually taken.
The change has already been fixed in the trunk and the 10.1 branch.

+1 to including DERBY-1392  and thanks so much to Anders for finding 
and fixing this issue!


Kathey




On the similar lines I would also wish to see DERBY-959 available in 
10.1.3, if there is an RC2. The fix looks  straight forward and at the 
same time will allow the Network server to match the newer DRDA spec and 
work with newer C clients.


Regards,
-Rajesh

Re: [VOTE] 10.1.3.0 release

2006-06-22 Thread Suresh Thalamati


Mike Matrigali wrote:

I would like to see the fix for DERBY-1392 included in the 10.1.3
release if there is a second release candidate.  While the bug
is an edge error case, the result is a corrupt db.  I believe
there is little risk as again the path is not one usually taken.
The change has already been fixed in the trunk and the 10.1 branch.

/mikem




I agree with Mike, DERBY-1392 fix  should be included in the second 
release candidate. Although it happens only on error case; it is good 
to fix this issue;  I think error path mentioned also can be hit when 
users interrupt thread when derby is writing pages with an 
InterrupedIOException. Fix  is simple, it should not cause any 
regressions.



Thanks
-suresht

Re: [VOTE] 10.1.3.0 release

2006-06-22 Thread Mike Matrigali




Andrew McIntyre wrote:

On 6/20/06, Kathey Marsden [EMAIL PROTECTED] wrote:


Mike Matrigali wrote:

 I would like to see the fix for DERBY-1392 included in the 10.1.3
 release if there is a second release candidate.  While the bug
 is an edge error case, the result is a corrupt db.  I believe
 there is little risk as again the path is not one usually taken.
 The change has already been fixed in the trunk and the 10.1 branch.

+1 to including DERBY-1392  and thanks so much to Anders for finding and
fixing this issue!



Is this a serious enough issue to warrant another release candidate?
Tests that exercise the issue were not contributed along with the fix,
and it would be nice to know that this is an issue that is likely to
be hit in known circumstances. If so, a release note is probably in
order since it supposedly can cause corruption to a database.


I believe this is serious enough to warrent another RC.  By code 
inspection as Anders points out it is clear there is a path that

could corrupt the db.

Another reason I would like to get this in is that in the past there
has been a non reproducible case of an unencrypted string getting
into a page of an encrypted db with one of our customers on the
original cloudscape pre-derby product.  We have
never been able to reproduce this, but the code for this path is
has the same problem in the pre-derby code as the code Anders fixed.
Since we never had a reproducible case I can't say this is the fix,
but it seems likely.

Because the code path depends on a timing I/O exception it is a 
particularly hard test to write.  For this reason I spent extra

time reviewing the code and why I felt it was ok to go in without
a test.

Since 10.2 is around the corner, I am worried that this might be the 
last official 10.1 release for a long time so would like to see this

fix make it.

[jira] Updated: (DERBY-1429) Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly

2006-06-22 Thread Mike Matrigali (JIRA)

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

Mike Matrigali updated DERBY-1429:
--

Component: Services
   (was: Store)

This issue  should be handled by the monitor, not the store.  

 Additional vulnerability to non-deterministic startup behavior when 
 applications generate derby properties on the fly
 -

  Key: DERBY-1429
  URL: http://issues.apache.org/jira/browse/DERBY-1429
  Project: Derby
 Type: Bug

   Components: Services
 Versions: 10.2.0.0
 Reporter: Rick Hillegas


 JDBC4 driver-autoloading, introduced by DERBY-930, increases the exposure to 
 non-deterministic startup behavior described in DERBY-1428. With the 
 introduction of driver-autloading, DERBY-1428 can be triggered if OtherApp is 
 any application which uses a JDBC driver. That is, OtherApp could use a Derby 
 client driver, the DB2JCC driver, the Oracle client driver, etc.. The extra 
 exposure arises because, with driver auto-loading, all JDBC drivers are 
 registered and the Derby engine boots the first time some application asks 
 for a Connection.
 The issues are summarized in an email thread 
 http://mail-archives.apache.org/mod_mbox/db-derby-dev/200606.mbox/browser and 
 bug report DERBY-1399.
 Workarounds are similar to those for DERBY-1428:
 1) Determine the derby properties BEFORE the VM starts.
 2) If that is not possible, then force the self-configuring embedded 
 application to run first.

-- 
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-1271) Release documentation for JDBC4 release

2006-06-22 Thread Jeff Levitt



--- Rick Hillegas [EMAIL PROTECTED] wrote:

 Daniel John Debrunner wrote:
 
 Rick Hillegas wrote:
 
   
 
 Jean T. Anderson wrote:
 
 
 
 Rick Hillegas wrote:
  
 
   
 
 Thanks, Jean. The Edition line turns up in the
 visible text which
 appears in the printed document. That makes me
 think that it applies to
 something that the customer, the reader, cares
 about. I don't think the
 reader is particularly concerned about our
 transition to dita. If that
 is what Edition is supposed to capture, perhaps
 the Edition lines should
 be moved to a comments section so that they will
 not be
 visible/confusing to customers.
   
 
 
 The Developers Guide has a first edition for
 both 10.0 and 10.1:
  

http://db.apache.org/derby/docs/10.0/manuals/develop/develop.html
  

http://db.apache.org/derby/docs/10.1/devguide/rdevcopyright.html
 
 I don't know why the Edition was bumped for the
 others. :-)
 
 If there isn't a major change to the content of
 the book, I don't think
 the edition should be bumped.
 
 Working With Derby should definitely not be
 bumped from First to
 Second edition since 10.2 will be its first
 release.
  
 
   
 
 I could just bump the edition for the Reference
 Guide, which will carry
 a lot of edits to reflect JDBC4. Would that be
 acceptable?
 
 
 
 What does the edition represent? Would this mean
 the first release of
 the 10.2 documentation set would be partially at
 the second edition,
 doesn't seem to make sense to me.
 
 Dan.
   
 
 This is what's troubling me too. From Jean's
 investigations it seems 
 that edition doesn't have a consistent meaning
 across our user guides 
 and releases. We could just remove the edition
 lines. If we leave them 
 in, then it would be good to agree on their meaning.
 Maybe one of the 
 following:
 
 1) The Edition number is bumped whenever we create a
 release branch. We 
 don't bump Edition for point or patch releases.
 
 2) The Edition number is bumped whenever reviewers
 agree that a user 
 guide has changed significantly.
 
 3) The Edition number is the same as the release
 number. All user guides 
 in a given release have identical Edition numbers.
 
 
 


As the person who contributed the DITA-converted
documentation, I can tell you I didn't bump the
edition up based on that.  I believe the pre-DITA
documentation already said Second Edition.  

The thought is that major releases (10.0, 10.1, 10.2)
are First Editions, and subsequent fixpaks are Second,
Third, Fourth editions etc., like 10.1.3 would be.  In
any case, we haven't adhered to any kind of
consistency on this with the guides, so I agree that
we need to define what we feel is an edition and
stick with it or remove it alltogether (although
perhaps there's a legal reason to keep it?)



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[jira] Updated: (DERBY-1343) It is possible to have duplicate entries in conglomerateId of sysconglomerates before DERBY-655 was fixed in 10.0 or 10.1 databases. It is desirable to patch these databas

2006-06-22 Thread Mike Matrigali (JIRA)

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

Mike Matrigali updated DERBY-1343:
--

Component: (was: Store)

this is an issue with the system catalogs, from discussions on list it looks 
like not a store issue.

 It is possible to have duplicate entries in conglomerateId of 
 sysconglomerates before DERBY-655 was fixed in 10.0 or 10.1 databases. It is 
 desirable to patch these databases on upgrade to 10.2 so conglomerateId 
 becomes unique again.
 

  Key: DERBY-1343
  URL: http://issues.apache.org/jira/browse/DERBY-1343
  Project: Derby
 Type: Bug

   Components: SQL
 Versions: 10.0.2.0
 Reporter: Mamta A. Satoor


 Because of an optimization implemented in before Derby 10.0 release, it is 
 possible to have duplicate entries in conglomerateId column. It would be good 
 to patch these entries during upgrade to 10.2 or later so that 
 conglomerateIds become unique again. See the discussion and proposed 
 solutions at:
 http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887
 When a user defines a constraint, Derby checks to see if it's backing index 
 is a duplicate of an existing index and if yes, then it shares the same 
 conglomerates for both such indexes. Code for this is in 
 org.apache.derby.impl.sql.execute.CreateIndexConstantAction.executeConstantAction.
  This causes Derby to have duplicate rows in sysconglomerates with same 
 conglomerateid. (More information on this can be found in thread 
 http://www.nabble.com/-Derby-655-+%3A+getImportedKeys+returns+duplicate+rows+in+some+cases-t1673189.html#a4535887
  titled [DERBY-655] : getImportedKeys returns duplicate rows in some cases.
 During drop constraint, it looks like Derby is not able to identify the 
 correct row in SYSCONGLOMERATES, if there are duplicate rows with same 
 conglomerateid and as a consequence, wrong row gets dropped in 
 SYSCONGLOMERATES. More information with an example on this can be found in 
 thread 
 http://www.nabble.com/When+foreign+key+is+dropped%2C+is+Derby+dropping+the+wrong+row+from+SYS.SYSCONGLOMERATES--t1654121.html#a4481463
  titled When foreign key is dropped, is Derby dropping the wrong row from 
 SYS.SYSCONGLOMERATES?

-- 
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-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db

2006-06-22 Thread Mike Matrigali (JIRA)

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

Mike Matrigali updated DERBY-1156:
--


i reviewed and tested reencrypt_3.diff patch.  it looks fine, i will let you 
commit.  Still would like to see more testing, especially exercising the abort 
paths when failure happens while reencrypting.

 allow the encrypting of an existing unencrypted db and allow the 
 re-encrypting of an existing encrypted db
 --

  Key: DERBY-1156
  URL: http://issues.apache.org/jira/browse/DERBY-1156
  Project: Derby
 Type: Improvement

   Components: Store
 Versions: 10.1.2.3
 Reporter: Mike Matrigali
 Assignee: Suresh Thalamati
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: encryptspec.html, reencrypt_1.diff, reencrypt_2.diff, 
 reencrypt_3.diff

 encrypted database to be re-encrypted with a new password.
 Here are some ideas for an initial implementation.
 The easiest way to do this is to make sure we have exclusive access to the
 data and that no log is required in the new copy of the db.  I want to avoid
 the log as it also is encrypted.  Here is my VERY high level plan:
 1) Force exclusive access by putting all the work in the low level store,
offline boot method.  We will do redo recovery as usual, but at the end
there will be an entry point to do the copy/encrypt operation.
 copy/encrypt process:
 0) The request to encrypt/re-encrypt the db will be handled with a new set
of url flags passed into store at boot time.  The new flags will provide
the same inputs as the current encrypt flags.  So at high level the
request will be connect db old_encrypt_url_flags; new_encrypt_url_flags.
TODO - provide exact new flag syntax.
 1) Open a transaction do all logged work to do the encryption.  All logging
will be done with existing encryption.
 2) Copy and encrypt every db file in the database.  The target files will
be in the data directory.  There will be a new suffix to track the new
files, similar to the current process used for handling drop table in
a transaction consistent manner without logging the entire table to the 
 log.
Entire encrypted destination file is guaranteed synced to disk before
transaction commits.  I don't think this part needs to be logged.
Files will be read from the cache using existing mechanism and written
directly into new encrypted files (new encrypted data does not end up in
the cache).
 3) Switch encrypted files for old files.  Do this under a new log operation
so the process can be correctly rolled back if the encrypt db operation
transaction fails.  Rollback will do file at a time switches, no reading
of encrypted data is necessary.
 4) log a change encryption of db log record, but do not update
system.properties with the change.
 5) commit transaction.
 6) update system.properties and sync changes.
 7) TODO - need someway to handle crash between steps 5 and 6.
 6) checkpoint all data, at this point guaranteed that there is no outstanding
transaction, so after checkpoint is done there is no need for the log.
 ISSUES:
 o there probably should be something that catches a request to encrypt to
   whatever db was already encrypted with.

-- 
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-1156) allow the encrypting of an existing unencrypted db and allow the re-encrypting of an existing encrypted db

2006-06-22 Thread Suresh Thalamati


Mike Matrigali (JIRA) wrote:

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

Mike Matrigali updated DERBY-1156:
--


i reviewed and tested reencrypt_3.diff patch.  it looks fine, i will let you commit.  Still would like to see more testing, 
especially exercising the abort paths when failure happens while reencrypting.





Thanks Mike. I will add the tests for abort paths.


-suresh

Re: [VOTE] 10.1.3.0 release


Andrew McIntyre wrote:


If we have another release candidate, and assuming that the relevant
fixes for it can be committed by Friday, are those testing the release
candidate comfortable with a 72-hour turnaround on the vote for the
new release candidate or will we need another two weeks?


I think for DERBY-1392 72 hours is just fine because.
1) Nobody has a test that goes through that code path anyway.
2) If anybody does go through that code path as it stands they get a 
corrupt db.


So it sounds like whatever the fix for DERBY-1392 holds it is only going 
to be better for users.



What else has gone into 10.1.3 since the release candidate?   I think it 
would be the other fixes that would dictate how much additional testing 
is required.


Kathey

Re: [VOTE] 10.1.3.0 release

2006-06-22 Thread Andreas Korneliussen


+1

Based on test results: 
http://www.multinet.no/~solberg/public/Apache/index.html



Andreas

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release

Jeff Levitt wrote:
snip

 As the person who contributed the DITA-converted
 documentation, I can tell you I didn't bump the
 edition up based on that.  I believe the pre-DITA
 documentation already said Second Edition.  

The pre-DITA (10.0) doc source says First Edition:

https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/getstart/gspr.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/reference/sqlj.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/develop/develop.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tools/tools.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/admin/hubprnt.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tuning/perf.ihtml

 The thought is that major releases (10.0, 10.1, 10.2)
 are First Editions, and subsequent fixpaks are Second,
 Third, Fourth editions etc., like 10.1.3 would be.  In
 any case, we haven't adhered to any kind of
 consistency on this with the guides, so I agree that
 we need to define what we feel is an edition and
 stick with it or remove it alltogether (although
 perhaps there's a legal reason to keep it?)

If we don't have a specific use for it, I recommend removing it. I don't
know of any legal reason to have it.

 -jean

Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release


+1

Regards,
-Rick

Jean T. Anderson wrote:


Jeff Levitt wrote:
snip

 


As the person who contributed the DITA-converted
documentation, I can tell you I didn't bump the
edition up based on that.  I believe the pre-DITA
documentation already said Second Edition.  
   



The pre-DITA (10.0) doc source says First Edition:

https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/getstart/gspr.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/reference/sqlj.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/develop/develop.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tools/tools.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/admin/hubprnt.ihtml
https://svn.apache.org/repos/asf/db/derby/docs/branches/10.0/src/documentation/content/xdocs/manuals/tuning/perf.ihtml

 


The thought is that major releases (10.0, 10.1, 10.2)
are First Editions, and subsequent fixpaks are Second,
Third, Fourth editions etc., like 10.1.3 would be.  In
any case, we haven't adhered to any kind of
consistency on this with the guides, so I agree that
we need to define what we feel is an edition and
stick with it or remove it alltogether (although
perhaps there's a legal reason to keep it?)
   



If we don't have a specific use for it, I recommend removing it. I don't
know of any legal reason to have it.
 


-jean

[jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application

2006-06-22 Thread Kathey Marsden (JIRA)

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

Kathey Marsden commented on DERBY-1275:
---

 I was wondering if anyone had any thoughts on how to implement this 
improvement to
provide a way to enable client tracing without changing the application

Not being able to turn on tracing in a deployed application without application 
code changes is a serious supportability issue because unless the application 
has a mechanism to configure settings like traceDirectory and traceLevel,  the 
application itself my have to be rebuilt to enable client tracing. Even when 
such a mechanism is provided it takes someone with knowledge of the application 
to turn it on, again a supportability issue. 

All I can think of is supporting System properties like 
derby.client.traceLevel.  We also could  mimic our server side mechanism and 
have a System property derby.client.home that points to a directory where  a 
file derby.client.properties can live and the trace files can go by default.  
The System property mechanism  raises a red flag for me because of class loader 
issues like we have for derby.system.home.  But maybe it is ok because of the 
diagnostic nature.

I ask this question because I find myself in need to put this into a debug 
build to send to a user and figure I might as well head down the correct path 
toward an ultimate solution.

Thoughts?


 Provide a way to enable client tracing without changing the application
 ---

  Key: DERBY-1275
  URL: http://issues.apache.org/jira/browse/DERBY-1275
  Project: Derby
 Type: Improvement

   Components: Network Client
 Versions: 10.2.0.0, 10.1.2.3
 Reporter: Kathey Marsden
 Priority: Minor


 Currently  the client tracing can be enabled by  setting attributes on the 
 client url, setXXX methods on the DataSource or calling 
 DriverManager.setLogWriter(), but it often cannot be enabled in a deployed 
 client application  because all of these API's require modification of the 
 application or its configuration files.
 It would be good to have a global way to turn on client tracing.  A system 
 property pointing to a property file is  one possibility but probably not 
 ideal because of the impact in class loader contexts.I am not sure what 
 the other possiblities are,

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

Proposal for 10.2 release schedule

Last week, Sun Microsystems announced that it will bundle Derby with the 
next major release of the reference jdk, Java SE 6, also known as 
Mustang or jdk1.6. If you download the latest Mustang build, you will 
see that it contains our Derby 10.2.0.3 snapshot in the db directory 
parallel to lib and bin.


This is big news. It means that over the course of the next year, Derby 
will turn up on the desktops of millions of developers. Hopefully, 
Derby's user and developer communities will both grow dramatically.


I would like to support this bundling. Note that Mustang will need our 
vetted 10.2 release candidate by September 15 so that they can QA it. 
This is expected to take about 5 weeks, after which Mustang should go GA 
in late October.


The JCP requires that our JDBC4-exposing release can not be generally 
available until the JDBC4 specification is finalized, which happens when 
Mustang is generally available. Until that date, this means that our 
final, vetted release candidate can not be officially stamped as GA  
and we can not promote it to the various Apache mirrors.


Here are proposed dates for 10.2 milestones:

August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2
End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache mirrors.

Are this proposal and its dates reasonable?

Copyright format (was Re: [jira] Updated: (DERBY-1271) Release documentation for JDBC4 release)

Rick Hillegas (JIRA) wrote:
  [ http://issues.apache.org/jira/browse/DERBY-1271?page=all ]
 
 Rick Hillegas updated DERBY-1271:
 -
 
 Attachment: derby-1271_copyrights.diff
 
 Attaching derby-1271_copyrights.diff. This adjusts dates in the visible 
 copyright notices in the user guides. Touches the following files:

regarding the format of the copyright, Rick did what I originally suggested:

 Copyright 1997, 2005-2006 The Apache Software Foundation or its licensors, as 
 applicable.

Looking at this more closely, all that is needed is the origin year and
the year of the most recent update:

   Copyright 1997, 2006 The Apache Software Foundation or its licensors,
as applicable.

 -jean

Re: Proposal for 10.2 release schedule


Rick Hillegas wrote:

The JCP requires that our JDBC4-exposing release can not be generally 
available until the JDBC4 specification is finalized.


Is this something that the Derby community is bound to?



Here are proposed dates for 10.2 milestones:

August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2


What happens between September 15 and End of October on the 10.2 branch?
Does bug fixing and work on 10.2.1 begin?
If we fix critical bugs during that time in the 10.2 branch can't they 
go into the release end of October?



End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache mirrors.

Re: Tuncation of trailing blanks and lengthless streaming overloads

2006-06-22 Thread Kristian Waagan


Daniel John Debrunner wrote:

Kristian Waagan wrote:

  

Hello,

I'm working on DERBY-1417; adding new lengthless overloads to the
streaming API.  So far, I have only been looking at implementing this in
the embedded driver. Based on some comments in the code, I have a few
questions and observations regarding truncation of trailing blanks in
the various character data types.

TypeTrail. blank trunc. Where

CHARallowed SQLChar.normalize
VARCHAR allowed SQLVarchar.normalize
LONG VARCHAR   disallowed   SQLLongVarchar.normalize
CLOBallowed streaming or
SQLVarchar.normalize, depending
on source.

As can be seen, only data for CLOB is truncated for trailing blanks in
the streaming class. We must still read all the data, or so much as we
need to know the insertion will fail, but we don't have to store it all
in memory.

Truncation of trailing blanks is not allowed at all for LONG VARCHAR
(according to code comments and bug 5592 - haven't found the place this
is stated in the specs).

My question is, should we do the truncate check for CHAR and VARCHAR on
the streaming level as well?
If we don't add this feature, inserting a
10GB file into a VARCHAR field by mistake will cause 10GB to be loaded
into memory even though the max size allowed is ~32K, possibly causing
out-of-memory errors. The error could be generated at an earlier stage
(possibly after reading ~32K +1 bytes).



I would say its a separate issue to the one you are addressing.
Applications most likely won't be inserting 10Gb values into
CHAR/VARCHAR columns using streams as it's not going to work.
Maybe enter a bug, but doesn't seem it has to be fixed as part of this
issue.
  


Handling this as a separate issue is better. The code changes would most 
likely go into the same class as my changes for DERBY-1417. It seems 
like a simple enough change, so I will enter a Jira improvement issue. I 
don't like getting an out-of-memory exception (heap).


  

As far as I can tell, adding this feature is a matter of modifying the
'ReaderToUTF8' class and the
'EmbedPrearedStatement.setCharacterStreamInternal' method.
One could also optimize the reading of data into LONG VARCHAR, where one
would abort the reading as soon as you can instead of taking it all into
memory first. This would require some special case handling in the
mentioned locations.


Another matter is that streams will not be checked for exact length
match when using the lengthless overloads, as we don't have a specified
length to compare against.
I have a preliminary implementation for setAsciiStream,
setCharacterStream  and setClob (all without length specifications) in
EmbedPreparedStatement.



What's the issue with setClob()? The current method doesn't take a
length. Has java.sql.Clob been changed to not always have a length?
  


There are/will be 3 setClob methods in PreparedStatement:
 1) setClob(int,Clob)
 2) setClob(int,Reader,long)
 3) setClob(int,Reader)

1) and 2) are already implemented, 3) is a new method added to JDBC. The 
same story goes for the other setXXXStream methods and updateXXXStream 
methods. These are located in PreparedStatement, CallableStatement and 
ResultSet.




--
Kristian


Dan.

Re: [PRE-VOTE DISCUSSION] Compatibility rules and interface table


David Van Couvering wrote:

Hi, Kathey, my silence (and I'm guessing the silence of others) was 
general approval of your comments.  Did you update the page?  I didn't 
see any change notifications fly by.



Finally did it.

What kind of clarification are you looking for?  I'm afraid I'm 
missing your point :(



nevermind.   Probably not important.  No time to pursue now.

Re: Proposal for 10.2 release schedule


Hi Kathey,

Thanks for raising these issues. Here are some clarifications.

Regards,
-Rick

Kathey Marsden wrote:


Rick Hillegas wrote:

The JCP requires that our JDBC4-exposing release can not be generally 
available until the JDBC4 specification is finalized.



Is this something that the Derby community is bound to?


The JCP rules are the license you accept when you publish a GA 
implementation of a JSR. In our case this is JSR 221, which governs 
JDBC4. The Derby community accepts this license by exposing a GA 
implementation of JDBC4 in release 10.2.






Here are proposed dates for 10.2 milestones:

August 10 - Feature work committed. 10.2 branch created.
August 24 - Last day to commit changes for 10.2
August 25 - Begin vetting 10.2 release candidate
September 15 - Target date for finishing the voting on Derby 10.2



What happens between September 15 and End of October on the 10.2 branch?


Between September 15 and the end of October, the vetted 10.2 release 
candidate is still available to anyone who needs it, just as the 10.1.3 
release candidate is available right now.



Does bug fixing and work on 10.2.1 begin?


Forgive me for being pedantic about release numbers. I think that the 
first release cut off the 10.2 branch will be called 10.2.1.0. I think 
that you are asking about bug fixing for the second release cut off the 
10.2 branch, which would be 10.2.2.0.


I think that we can begin putting more bug fixes into the 10.2 branch as 
soon as we produce the first 10.2 release candidate. So that would be 
mid-September.


If we fix critical bugs during that time in the 10.2 branch can't they 
go into the release end of October?


Suppose we were able to publish the 10.2 release candidate (make it GA) 
right after we vetted it in mid-September. When would you want to 
produce the follow-on bug fix release? At the end of October? A couple 
months later? We could do either. The community may want to defer the 
follow-on bug fix release for a couple months. That would give us time 
to collect more feedback from users of the published, GA release. 
However, we could release early, release often and produce another 
release from the 10.2 branch at the end of October.





End of October - Expected GA of JDBC4 with Mustang
End of October - GA of Derby 10.2. Release promoted to Apache mirrors.

Re: Proposal for 10.2 release schedule

Rick Hillegas wrote:

 Last week, Sun Microsystems announced that it will bundle Derby with the
 next major release of the reference jdk, Java SE 6, also known as
 Mustang or jdk1.6. 

To be precise, Sun Microsystems announced that it will bundle Java DB
with Mustang.

http://biz.yahoo.com/prnews/060621/sfw063.html?.v=66

Dan.

Re: Proposal for 10.2 release schedule

Rick Hillegas wrote:


 Kathey Marsden wrote:
 
 Rick Hillegas wrote:


 What happens between September 15 and End of October on the 10.2 branch?
 

 If we fix critical bugs during that time in the 10.2 branch can't they
 go into the release end of October?

They should be able to. Since we won't have had a GA release (JCP rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require a new
release candidate and new vote. Could even be a database format change.

 Suppose we were able to publish the 10.2 release candidate (make it GA)
 right after we vetted it in mid-September. When would you want to
 produce the follow-on bug fix release? At the end of October? A couple
 months later? We could do either. The community may want to defer the
 follow-on bug fix release for a couple months. That would give us time
 to collect more feedback from users of the published, GA release.
 However, we could release early, release often and produce another
 release from the 10.2 branch at the end of October.

Not sure I understand the point of this paragraph. I thought the JCP
rules mean we can't make 10.2 GA in mid-Sep, thus it seems to be a
hypothetical impossible situation.

Dan.

[jira] Created: (DERBY-1441) Allow client to be able to send greater than 32k query block size.

2006-06-22 Thread Sunitha Kambhampati (JIRA)

Allow client to be able to send greater than 32k query block size. 
---

 Key: DERBY-1441
 URL: http://issues.apache.org/jira/browse/DERBY-1441
 Project: Derby
Type: Improvement

  Components: Network Client  
Versions: 10.2.0.0
Reporter: Sunitha Kambhampati
Priority: Minor


DERBY-959  talks about 'Allowing use of QRYDTA block sizes greater than 32k'.   
I am opening two tasks after the discussion on DERBY-959. 

As part of this issue:
- add support in client to be able to send query block size of greater than 
32k.  

After that, some benchmarking needs to be done to choose a good query block 
size for the client to send to the server. I'll open another jira for the 
performance analysis task. 

Here is the link to the discussion that happened for DERBY-959.
http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273

-- 
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-1442) Do performance analysis and come up with a good query block size value for the client to send to the server

2006-06-22 Thread Sunitha Kambhampati (JIRA)

Do performance analysis and come up with a good query block size value for the 
client to send to the server
---

 Key: DERBY-1442
 URL: http://issues.apache.org/jira/browse/DERBY-1442
 Project: Derby
Type: Improvement

  Components: Network Server, Test, Network Client, Performance  
Reporter: Sunitha Kambhampati
Priority: Minor
 Fix For: 10.2.0.0


Do performance analysis, and find a good query block size value for the client 
to send to the server . Need to understand the memory usage also for greater 
query block size values. 

This issue is related  to DERBY-959 and DERBY-1441.

DERBY-959 has server side changes
DERBY-1441 issue talks about client side changes

DERBY-959  talks about 'Allowing use of QRYDTA block sizes greater than 32k'.  
As part of discussion on that jira, it was suggested that the performance 
analysis to decide a good query block size value for the client to send to the 
server be a separate task.  

Here is the link to the discussion that happened for DERBY-959.
http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273


-- 
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-959) Allow use of DRDA QRYDTA block sizes greater than 32K

2006-06-22 Thread Sunitha Kambhampati (JIRA)

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

Sunitha Kambhampati commented on DERBY-959:
---

Discussion happened on this issue on derby-dev. Here is the link to the
discussion that happened on derby-dev
http://www.nabble.com/-jira--Created%3A-%28DERBY-959%29-Allow-use-of-DRDA-QRYDTA-block-sizes-greater-than-32K-t1106974.html#a2892273

I have opened two other jira issues for the tasks related to this issue. .
DERBY-1441 - client side changes to support query block size greater than 32k
DERBY-1442- to do performance analysis and come up with a 'good' query block
size value for the client to send to the server.

Allow use of DRDA QRYDTA block sizes greater than 32K
-

Key: DERBY-959
URL: http://issues.apache.org/jira/browse/DERBY-959
Project: Derby
Type: Improvement

Components: Network Client, Performance, Network Server
Versions: 10.1.1.0, 10.2.0.0, 10.1.1.1, 10.1.1.2
Reporter: Bryan Pendleton
Priority: Minor
Attachments: 959Notes_v1.html, SmallRows_32kBlkSz.trace,
SmallRows_64kBlkSz.trace, derby959.review.diff.txt, derby959.review.stat.txt,
odbc_rowgreaterthan64k.trace

Currently, the Network Server and Network Client use a 32K blocksize when
returning database data in QRYDTA blocks.
I came across the following statement in the DRDA spec (Volume 1, page 12):
Blocking applies only to the QRYDTA reply objects. Each
query block is a QRYDTA DSS. The maximum query block size
value allowed in the qryblksz parameter is increased from
32K to 10M, thus accomodating the larger data volumes
required by modern, more data-intensive applications.
The importance of larger block sizes depends strong on the application
profile.. For example, many applications perform single-record selects,
and they are not influenced by the block size.
But for some applications, it seems like the ability to use a larger block
size could be quite valuable.

--
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: [PRE-VOTE DISCUSSION] Compatibility rules and interface table

Under Deprecated there is:

A deprecated interface may be removed from the project after four minor
and/or major releases.

http://wiki.apache.org/db-derby/ForwardCompatibility#head-b94fc1d3af5d38a917e2b6c754a8c4213e28f06e

Not sure that really works. With an open source project there could be
four releases in a couple of months, would allow features to be
deprecated very quickly.

Not sure of any better wording.

Dan.

Re: MySQL to Derby Migration Tool

Ramin Moazeni wrote:
 Hello,
 
 I am a Google Summer of code participant working on the Derby
 Migration tool project. The High level design document is posted at
 http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument

It's great to see you doing this!

 There are 2 approaches described in the document -- one based on the use
 DatabaseMetaData class and the other is based on the use ddlUtils tool
 (http://db.apache.org/ddlutils) which is also an apache project.

In the Approach 2: Using DdlUtils section of
http://wiki.apache.org/db-derby/MysqlDerbyMigration/DesignDocument ,
there is this description:

   In order to use DdlUtils component to migrate the source database
   to the target database, following steps are suggested:

* Capture DDL file from DdlUtils.
* Modify the source DDL to the target DDL using Serialization and
Deserialization of XML.
* Fed in the new DDL file to the DdlUtils.

If the intent is to use the XML DDL file generated by DdlUtils,
technically there should be no need to modify it for the target database
-- except that there are a few issues that would need to be watched for,
such as Derby doesn't support a boolean type. At any rate, the Java app
can read the database model from the XML file, or even from the live
database (see
http://db.apache.org/ddlutils/api-usage.html#Reading+the+model+from+a+live+database
), then write that database model to the target. The DdlUtils code takes
care of producing the SQL required to create the tables in the new database.

 Please note that the DdlUtils doesn’t support non-table entities, 
 constraints, triggers, stored procedures, etc. 

DdlUtils supports primary and foreign key constraints, but not check
constraints.

Given its limitations, your DatabaseMetaData approach might be more
complete. But if you can use any pieces from DdlUtils, you should feel
free to do so (with all the correct attributions, of course) since it is
under the ASL 2.0.

 -jean

Re: Proposal for 10.2 release schedule

Rick Hillegas wrote:

 Hi Dan,
 
 Thanks for your comments. Some further remarks follow.
 
 Regards,
 -Rick
 
 Daniel John Debrunner wrote:
 
 Rick Hillegas wrote:


  

 Kathey Marsden wrote:

   

 Rick Hillegas wrote:

 


  

 What happens between September 15 and End of October on the 10.2
 branch?
 


  

 If we fix critical bugs during that time in the 10.2 branch can't they
 go into the release end of October?
 


 They should be able to. Since we won't have had a GA release (JCP rules)
 until Mustang ships, it seems any critical bug that we find and fix
 between Sep 15th and Mustang shipping has the potential to require a new
 release candidate and new vote. Could even be a database format change.
  

 Let me work out the implications of this.
 
 o Mustang would ship with a release candidate which the community rejected.
 o The community would approve a later release candidate and promote it
 to GA status.
 o Bug reports would come in against both the rejected candidate bundled
 into Mustang and the approved candidate which was promoted to GA status.
 
 A couple issues come to mind:
 
 o In those bug reports, how would we disambiguate the release
 candidates? We could bump the last digit of the release identifier after
 producing the first candidate. Or we could rely on the full version id
 produced by sysinfo, which contains the subversion revision number.

I think we have bumped the fourth version (point) digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.

 o The database format change troubles me. What happens if someone
 creates a database with the rejected release candidate bundled with
 Mustang? I think we want that database to play well with the approved
 release candidate which goes GA.

The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.

Dan.

Re: Proposal for 10.2 release schedule


Daniel John Debrunner wrote:


Rick Hillegas wrote:

 


Hi Dan,

Thanks for your comments. Some further remarks follow.

Regards,
-Rick

Daniel John Debrunner wrote:

   


Rick Hillegas wrote:




 


Kathey Marsden wrote:

 

   


Rick Hillegas wrote:

   
 




 


What happens between September 15 and End of October on the 10.2
branch?
   
 




 


If we fix critical bugs during that time in the 10.2 branch can't they
go into the release end of October?
   
 


They should be able to. Since we won't have had a GA release (JCP rules)
until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require a new
release candidate and new vote. Could even be a database format change.


 


Let me work out the implications of this.

o Mustang would ship with a release candidate which the community rejected.
o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA status.

A couple issues come to mind:

o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier after
producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
   



I think we have bumped the fourth version (point) digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.

 


o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
   



The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
 

I apologize for creating confusion here. We'd like Mustang to ship with 
a fully functional Derby, which creates upgradeable databases. So I'm 
assuming that we turn off the beta marker on the vetted candidate before 
handing the candidate to Mustang for QA bake-in.



Dan.

Re: Proposal for 10.2 release schedule


Rick Hillegas wrote:


Daniel John Debrunner wrote:


Rick Hillegas wrote:

 


Hi Dan,

Thanks for your comments. Some further remarks follow.

Regards,
-Rick

Daniel John Debrunner wrote:

  


Rick Hillegas wrote:







Kathey Marsden wrote:

 

  


Rick Hillegas wrote:

   








What happens between September 15 and End of October on the 10.2
branch?
   







If we fix critical bugs during that time in the 10.2 branch can't 
they

go into the release end of October?
   


They should be able to. Since we won't have had a GA release (JCP 
rules)

until Mustang ships, it seems any critical bug that we find and fix
between Sep 15th and Mustang shipping has the potential to require 
a new
release candidate and new vote. Could even be a database format 
change.






Let me work out the implications of this.

o Mustang would ship with a release candidate which the community 
rejected.

o The community would approve a later release candidate and promote it
to GA status.
o Bug reports would come in against both the rejected candidate bundled
into Mustang and the approved candidate which was promoted to GA 
status.


A couple issues come to mind:

o In those bug reports, how would we disambiguate the release
candidates? We could bump the last digit of the release identifier 
after

producing the first candidate. Or we could rely on the full version id
produced by sysinfo, which contains the subversion revision number.
  



I think we have bumped the fourth version (point) digit after
producing a release candidate. That can be done pretty much at any time,
so no issues disambiguating release candidates.

 


o The database format change troubles me. What happens if someone
creates a database with the rejected release candidate bundled with
Mustang? I think we want that database to play well with the approved
release candidate which goes GA.
  



The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
 

I apologize for creating confusion here. We'd like Mustang to ship 
with a fully functional Derby, which creates upgradeable databases. So 
I'm assuming that we turn off the beta marker on the vetted candidate 
before handing the candidate to Mustang for QA bake-in.


Re-reading your comment, I see another issue which I need to clarify. 
The release candidate is not a GA implementation under the JCP as I 
understand this process. The candidate does not become GA until we post 
it on the Apache mirrors and announce, via the Derby website, that it is 
the latest Derby release.

Re: Proposal for 10.2 release schedule

Rick Hillegas wrote:

 Daniel John Debrunner wrote:

 The mid-Sep Derby release candidate will be marked alpha or beta (JCP
 rules) so the databases won't upgrade anyway.
  

 I apologize for creating confusion here. We'd like Mustang to ship with
 a fully functional Derby, which creates upgradeable databases. So I'm
 assuming that we turn off the beta marker on the vetted candidate before
 handing the candidate to Mustang for QA bake-in.

Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
until Mustang ships. How can it be marked GA without violating the JCP
requirements.

Sorry if I'm being dense.
Dan.

[jira] Updated: (DERBY-1320) Test lang/procedure.java fails with ibm1.5 jvm

2006-06-22 Thread Manjula Kutty (JIRA)

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

Manjula Kutty updated DERBY-1320:
-

Attachment: procedure.java

 Test lang/procedure.java fails with ibm1.5 jvm
 --

  Key: DERBY-1320
  URL: http://issues.apache.org/jira/browse/DERBY-1320
  Project: Derby
 Type: Bug

   Components: Unknown, Regression Test Failure
 Versions: 10.2.0.0
  Environment: IBM 1.5 JVM /linux 
 Reporter: Sunitha Kambhampati
 Priority: Minor
  Fix For: 10.2.0.0
  Attachments: procedure.diff, procedure.java

 lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to 
 Manjula who filed DERBY-1108 that this is related to that issue and is a JVM 
 bug. The JVM team has been notified.Please note: I have marked this as a 
 Regression Test Failure although this test has not passed with IBM 1.5 JVM 
 atleast in our nightly regression test runs,  so it is not a regression of 
 the product. 
 diff:
 * Diff file derbyall/derbylang/procedure.diff
 *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 ***
 1018 del
  testImplicitClose(): PASSED
 1018 add
  testImplicitClose(): FAILED (no exception thrown)
 Test Failed.
 *** End:   procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 ***
 here is machine info.
 -- Java Information --
 Java Version:1.5.0
 Java Vendor: IBM Corporation
 Java home:   /local1/cloudtst/dev/src/ibm15/jre
 Java classpath:  
 /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar:
 OS name: Linux
 OS architecture: x86
 OS version:  2.6.5-7.252-bigsmp
 Java user name:  cloudtst
 Java user home:  /u/cloudtst
 Java user dir:   
 /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall
 java.specification.name: Java Platform API Specification
 java.specification.version: 1.5
 - Derby Information 
 JRE - JDBC: J2SE 5.0 - JDBC 3.0
 [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653)
 [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - 
 (405653)
 [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653)
 [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - 
 (405653)
 [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90)
 [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90)
 --

-- 
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: Proposal for 10.2 release schedule

Ok, this is very tricky.  First, I'd like to make sure we're on the same 
page here about Java DB going into the JDK.  I think in general the 
community thinks it's a good thing for Derby for Java DB to be in the 
JDK.  It gives us great exposure and distribution.  I also think the 
community would probably like it if databases created by the version of 
Java DB to be upgradable to a subsequent release of Derby, so that users 
can get the latest and greatest functionality of Derby directly from the 
Apache web site, or even upgrade to a future release of Cloudscape if 
they decide to get support from IBM.


In order for this to work, we need Java DB to be based on an official, 
GA-ready release of Derby to be what Sun redistributes in Mustang. 
Otherwise databases created in Mustang will be locked in to Java DB.


The problem is that it can't *actually* be GA until after JCP approves 
JSR 221, JDBC 4.0, which will happen in tandem with the GA release of 
the JDK, around 5 weeks after the JDK team needs their final integration 
bits from all the pieces going into it.


I think what Rick is asking for is a release that is voted as 
GA-ready, has the GA-bit turned on, but because of JCP rules is not 
actually *made* generally available until JSR 220 becomes final.  Since 
we all need to vet this release and approve it, it would be available to 
the Derby community, but not *generally* available by distributing it on 
all the Apache mirrors.


I know this seems like a fine hair to split, but it's the only way we 
can be successful without Sun having to do a non-upgradable fork of 
Derby, which I don't think any of us want.


I hope this helps to clear things up, even if it doesn't make things 
simpler :)


David

Daniel John Debrunner wrote:

Rick Hillegas wrote:


Daniel John Debrunner wrote:



The mid-Sep Derby release candidate will be marked alpha or beta (JCP
rules) so the databases won't upgrade anyway.
 


I apologize for creating confusion here. We'd like Mustang to ship with
a fully functional Derby, which creates upgradeable databases. So I'm
assuming that we turn off the beta marker on the vetted candidate before
handing the candidate to Mustang for QA bake-in.


Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA
until Mustang ships. How can it be marked GA without violating the JCP
requirements.

Sorry if I'm being dense.
Dan.

Re: Proposal for 10.2 release schedule

David Van Couvering wrote:
...
 In order for this to work, we need Java DB to be based on an official,
 GA-ready release of Derby to be what Sun redistributes in Mustang.
 Otherwise databases created in Mustang will be locked in to Java DB.
 
 The problem is that it can't *actually* be GA until after JCP approves
 JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
 the JDK, around 5 weeks after the JDK team needs their final integration
 bits from all the pieces going into it.

in other words, we have a classic catch-22. :-)

 I think what Rick is asking for is a release that is voted as
 GA-ready, has the GA-bit turned on, but because of JCP rules is not
 actually *made* generally available until JSR 220 becomes final.  Since
 we all need to vet this release and approve it, it would be available to
 the Derby community, but not *generally* available by distributing it on
 all the Apache mirrors.

It would still be easily available. And once downloaded, and probably
redistributed further, downstream users would have no idea that they
aren't working with an official Apache release.

What is the specific legal verbiage we're working with here?

 -jean

 I know this seems like a fine hair to split, but it's the only way we
 can be successful without Sun having to do a non-upgradable fork of
 Derby, which I don't think any of us want.
 
 I hope this helps to clear things up, even if it doesn't make things
 simpler :)
 
 David

Re: Proposal for 10.2 release schedule

Jean T. Anderson wrote:

 David Van Couvering wrote:
 ...
 
In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.

The problem is that it can't *actually* be GA until after JCP approves
JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
the JDK, around 5 weeks after the JDK team needs their final integration
bits from all the pieces going into it.
 
 
 in other words, we have a classic catch-22. :-)

Are there any dates around JDBC 4.0/JSR221 that need to be factored in?

I'm curious as to how we can vote on the release that's supporting JDBC
4.0 if the spec isn't final and/or generally available for people to
read. Maybe we would be just voting on the current functionality of
*Derby* and if it happens to match JDBC 4.0 that's a bonus.

Dan.

Re: Proposal for 10.2 release schedule

Andrew McIntyre wrote:

 Call in the lawyers:
 
 From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
 
 has executed, being a JCP Member (they've even got quotes from Geir
 prominently featured on their about JCP 2.6 page [2]):
 
 5.B. License to Create Independent Implementations.

Dumb question, is Derby:

 - creating an independent implementation of JSR221
 - or is it implementing a driver that adheres to JSR221?

I would say Apache Harmony (when/if they tackle Jave SE 6) would be
creating an independent implementation of JSR221 and that Derby is not.

Dan.

Re: Proposal for 10.2 release schedule


Jean and Dan, you raise good points

(a) what happens if someone downloads this GA-ready but not GA release 
of Derby.  If for some reason we have to do a respin of the release (see 
(b)), how will they later know that it's not actually an official 
release of Apache?


(b) is there a possibility, however, slight, that the JDBC spec could 
change after we have marked a release GA-ready


I think these are great points for discussion.

I get the sense that we all want to make this work, but are not sure how 
just yet.


I have a suggestion, and I'm sure I'm missing something, but here goes. 
 Is there a way we can vote on the release, and if it passes, Rick can 
flip the GA bit, sign it and put it on the shelf, but not make it 
available for download, even from the Derby site?  This would allow us 
to re-spin if necessary (although I don't think it's likely) due to a 
last-minute change to JDBC, and would prevent a user from ending up with 
a release that looks and smells like it's an official Apache release but 
actually isn't.


David

Daniel John Debrunner wrote:

Jean T. Anderson wrote:


David Van Couvering wrote:
...


In order for this to work, we need Java DB to be based on an official,
GA-ready release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be locked in to Java DB.

The problem is that it can't *actually* be GA until after JCP approves
JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
the JDK, around 5 weeks after the JDK team needs their final integration
bits from all the pieces going into it.


in other words, we have a classic catch-22. :-)


Are there any dates around JDBC 4.0/JSR221 that need to be factored in?

I'm curious as to how we can vote on the release that's supporting JDBC
4.0 if the spec isn't final and/or generally available for people to
read. Maybe we would be just voting on the current functionality of
*Derby* and if it happens to match JDBC 4.0 that's a bonus.

Dan.

[jira] Commented: (DERBY-1434) Client can send incorrect database name to server after having made multiple connections to different databases.

2006-06-22 Thread Kathey Marsden (JIRA)

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

Kathey Marsden commented on DERBY-1434:
---

Wish I could delete the comment but the early closed result set with is issue 
is not a valid symptom.  This wrong line caused the test to fail.  Should have 
been ps2.

ResultSet rs2 = ps.executeQuery(); 

 Client can send incorrect database name to server after having made multiple 
 connections to different databases.
 

  Key: DERBY-1434
  URL: http://issues.apache.org/jira/browse/DERBY-1434
  Project: Derby
 Type: Bug

   Components: Network Client
 Versions: 10.2.0.0, 10.1.3.0, 10.1.2.5
 Reporter: A B
  Fix For: 10.2.0.0
  Attachments: Server2.trace, _driver_1, d1434.java

 I have a simple program that connects to a database using the Derby Client, 
 executes a simple query, then connects to a different database using a 
 different Connection object and executes another simple query on that second 
 connection.  The queries both execute without error, so it appears that the 
 connections are correct--i.e. each query will only work on one of the 
 databases, and both queries work, therefore each must be getting executed 
 against the correct database.
 But in looking at the client and server traces, I noticed that for the query 
 on the second database, the client is actually sending the name of the 
 *first* database as RDBNAM, which (I think?) is wrong--it should be sending 
 the name of the second database, since the query is being executed on the 
 second Connection object.
 This behavior does not appear to occur for JCC.

-- 
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: Proposal for 10.2 release schedule


Andrew McIntyre wrote:

Anyway, what's the trigger for breaching the contract here? If it's
'creation' alone, then rolling that release candidate surely qualifies
as as creation. If it's 'creation and distribution,' well, is posting
the release candidate in a public forum and on a public website (like
one would have to do to vote on it) considered distribution in this
case? I have no idea, because i'm not a lawyer.


I don't either.  I will try and get someone here to discuss this with 
the JCP lawyers and try and get some clarification about 'creation' vs. 
'creation and distribution'.  I can't see how you can be in trouble for 
creating a set of bits that nobody has access to, but IANAL.


I guess you have somewhat answered my question from my other email: you 
must, even temporarily, make the official GA bits available for 
download, just so we can vote on the release.


Could we remove the download once it's voted on, at least to keep the 
window of vulnerability to a minimum?  I'm not saying that would satisfy 
the lawyers, but I'd like to know what is possible before we talk to them.


How do we handle this normally, if you create a release candidate with 
the GA bit set, and then we reject the release.  Don't we have the same 
problem already, with people getting access to a release that looks and 
smells like an official Apache release but actually isn't?




Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]



Even if we did ask Geir, he's not the last word on it. I'd rather hear 
it from the horse's mouth.  I or someone else will get back to you.


Thanks for all your input, and your research!


andrew

p.s. I'm assuming there's no TCK for JSR-221.


P.S. I am pretty sure there is, but as I understand it, it just 
validates the interfaces are there.  It's part of the overall TCK for 
Java SE 6, is my understanding.  I am sure Lance will be happy to clarify.




[1] http://www.jcp.org/aboutJava/communityprocess/JSPA2.pdf
[2] http://jcp.org/aboutJava/communityprocess/announce/2004/JCP2.6.html
[3] 
http://www.apache.org/foundation/records/minutes/2005/board_minutes_2005_12_21.txt 


(search for SUN ISSUES)

Re: Proposal for 10.2 release schedule

2006-06-22 Thread Lance J. Andersen







Daniel John Debrunner wrote:

  Andrew McIntyre wrote:

  
  
Call in the lawyers:



  From JSPA - 2.0.1 10 January 2005 [1], which presumably the ASF board
  

has executed, being a JCP Member (they've even got quotes from Geir
prominently featured on their "about JCP 2.6 page" [2]):

5.B. License to Create Independent Implementations.

  
  
Dumb question, is Derby:

 - creating an independent implementation of JSR221
 - or is it implementing a driver that adheres to JSR221?

I would say Apache Harmony (when/if they tackle Jave SE 6) would be
creating an independent implementation of JSR221 and that Derby is not.
  

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
final.

The Derby Embedded and Network Client drivers provide implementations
of the JDBC drivers based on JSR 221.


A Java SE implementation provides the interfaces and concrete classes
that are used by a JDBC driver for the given Java SE implementation.

JSR 221 falls under the umbrella spec for Java SE 6. They all go final
together.

  
Dan.

Re: Proposal for 10.2 release schedule

2006-06-22 Thread Rob Stephens





that was MUCH clearer than what rick wrote.. thanks

David Van Couvering wrote:
Ok, this is
very tricky. First, I'd like to make sure we're on the same page here
about Java DB going into the JDK. I think in general the community
thinks it's a good thing for Derby for Java DB to be in the JDK. It
gives us great exposure and distribution. I also think the community
would probably like it if databases created by the version of Java DB
to be upgradable to a subsequent release of Derby, so that users can
get the latest and greatest functionality of Derby directly from the
Apache web site, or even upgrade to a future release of Cloudscape if
they decide to get support from IBM.
  
  
In order for this to work, we need Java DB to be based on an official,
"GA-ready" release of Derby to be what Sun redistributes in Mustang.
Otherwise databases created in Mustang will be "locked in" to Java DB.
  
  
The problem is that it can't *actually* be GA until after JCP approves
JSR 221, JDBC 4.0, which will happen in tandem with the GA release of
the JDK, around 5 weeks after the JDK team needs their final
integration bits from all the pieces going into it.
  
  
I think what Rick is asking for is a release that is voted as
"GA-ready", has the GA-bit turned on, but because of JCP rules is not
actually *made* generally available until JSR 220 becomes final. Since
we all need to vet this release and approve it, it would be available
to the Derby community, but not *generally* available by distributing
it on all the Apache mirrors.
  
  
I know this seems like a fine hair to split, but it's the only way we
can be successful without Sun having to do a non-upgradable fork of
Derby, which I don't think any of us want.
  
  
I hope this helps to clear things up, even if it doesn't make things
simpler :)
  
  
David
  
  
Daniel John Debrunner wrote:
  
  Rick Hillegas wrote:


Daniel John Debrunner wrote:
  



  The mid-Sep Derby release candidate will
be marked alpha or beta (JCP

rules) so the databases won't upgrade anyway.




  
I apologize for creating confusion here. We'd like Mustang to ship with
  
a fully functional Derby, which creates upgradeable databases. So I'm
  
assuming that we turn off the beta marker on the vetted candidate
before
  
handing the candidate to Mustang for QA bake-in.
  


Sorry, I don't understand, I thought Derby 10.2 cannot be marked GA

until Mustang ships. How can it be marked GA without violating the JCP

requirements.


Sorry if I'm being dense.

Dan.



  


-- 

  

  
Rob Stephens 
Chief of Staff, Database Technology Group
OPG
  Sun Microsystems, Inc.
Bay Area, California US
Phone 1-877-244-4740 or x51734
Mobile 1-510-928-2996
Fax 1-877-244-4740
Email [EMAIL PROTECTED]

Re: Proposal for 10.2 release schedule

David Van Couvering wrote:

 Andrew McIntyre wrote:

 Or maybe ask Geir, since he's VP of Java Community Process for the
 Apache Software Foundation, since similar instances may have come up
 fairly recently. [3]

 
 Even if we did ask Geir, he's not the last word on it. I'd rather hear
 it from the horse's mouth.  I or someone else will get back to you.

From the ASF point of view, which is what we are discussing here, I
rather think Geir is the horse's mouth. It's the ASF's interpretation
of the licence the ASF signed and the risks the ASF is willing to take
that matter with a Apache Derby release.

Dan.

Re: Proposal for 10.2 release schedule


Lance J. Andersen wrote:
  

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.


Are you *sure* you can't *have* a GA version, e.g the bits can't exist 
somewhere, as long as they're not officially declared generally 
available?  If we can't even create the bits, then it is physically and 
logically impossible for us to give anything to the JDK team for 
integration.


Personally, I think we need to get clarification from the JCP folks on 
this before we make any final conclusions about this.


Thanks,

David

Re: Proposal for 10.2 release schedule


OK, good point, thanks.

David

Daniel John Debrunner wrote:

David Van Couvering wrote:


Andrew McIntyre wrote:



Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]


Even if we did ask Geir, he's not the last word on it. I'd rather hear
it from the horse's mouth.  I or someone else will get back to you.


From the ASF point of view, which is what we are discussing here, I
rather think Geir is the horse's mouth. It's the ASF's interpretation
of the licence the ASF signed and the risks the ASF is willing to take
that matter with a Apache Derby release.

Dan.

Re: Proposal for 10.2 release schedule


Hi, Lance.  Sorry I had to challenge you publicly on the list, but
I'm really worried that if we're not very careful we are going to paint 
ourselves into a corner and we are going to have to fork Derby in order 
to do a Java DB release.


I think we need the JCP lawyers (and it sounds like the ASF lawyers) to 
weigh in on this question before we make any conclusions that could 
cause us real trouble.


Thanks,

David


David Van Couvering wrote:

Lance J. Andersen wrote:
  

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.


Are you *sure* you can't *have* a GA version, e.g the bits can't exist 
somewhere, as long as they're not officially declared generally 
available?  If we can't even create the bits, then it is physically and 
logically impossible for us to give anything to the JDK team for 
integration.


Personally, I think we need to get clarification from the JCP folks on 
this before we make any final conclusions about this.


Thanks,

David

Re: Proposal for 10.2 release schedule

That said, it's probably also good to hear from the JCP as well.  It 
would probably help the ASF gauge what their exposure is and what 
approaches they feel comfortable with.


David

David Van Couvering wrote:

OK, good point, thanks.

David

Daniel John Debrunner wrote:

David Van Couvering wrote:


Andrew McIntyre wrote:



Or maybe ask Geir, since he's VP of Java Community Process for the
Apache Software Foundation, since similar instances may have come up
fairly recently. [3]


Even if we did ask Geir, he's not the last word on it. I'd rather hear
it from the horse's mouth.  I or someone else will get back to you.


From the ASF point of view, which is what we are discussing here, I
rather think Geir is the horse's mouth. It's the ASF's interpretation
of the licence the ASF signed and the risks the ASF is willing to take
that matter with a Apache Derby release.

Dan.

Re: Proposal for 10.2 release schedule

2006-06-22 Thread Lance J. Andersen




David Van Couvering wrote:

Lance J. Andersen wrote:
  
You cannot have a GA version of a JDBC 4 driver until JSR 221 goes 
final.


Are you *sure* you can't *have* a GA version, e.g the bits can't exist 
somewhere, as long as they're not officially declared generally 
available?  If we can't even create the bits, then it is physically 
and logically impossible for us to give anything to the JDK team for 
integration.
I think we are talking different things here as you are talking about 
getting your final version of your product ready to be released based on 
a JSR which is getting ready to go final , which is fine, which is 
different from what i was trying to say.


http://jcp.org/en/resources/guide#fab  gives you an overview of how a 
JSR goes final.







Personally, I think we need to get clarification from the JCP folks on 
this before we make any final conclusions about this.


Thanks,

David

Re: Proposal for 10.2 release schedule

2006-06-22 Thread Craig L Russell

Hi,Jean commented on David's post:... In order for this to work, we need Java DB to be based on an official,"GA-ready" release of Derby to be what Sun redistributes in Mustang.Otherwise databases created in Mustang will be "locked in" to Java DB.The problem is that it can't *actually* be GA until after JCP approvesJSR 221, JDBC 4.0, which will happen in tandem with the GA release ofthe JDK, around 5 weeks after the JDK team needs their final integrationbits from all the pieces going into it. in other words, we have a classic catch-22. :-)No, not at all. What happens right now is that we publish a release candidate that is available for the Derby community to test and vote on. Once the vote is complete, the release manager ties up some of the loose ends (records the vote results, pushes the bits around) and publishes the release on the Apache mirrors. Subsequently, other loose ends are tied (official announcement on Apache general email alias).What Rick is proposing to happen is for the community to vote and subsequently tie up some loose ends (record the vote results, send the bits to the Mustang folks instead of to the Apache mirrors). Once the Mustang release is official, continue tying up loose ends (publish the release on the Apache mirrors). And more loose ends (official announcement on Apache general email alias). So the only thing that changes compared to today is the delay that Rick mentioned between community approval of the bits and posting the bits to the Apache mirrors. I think what Rick is asking for is a release that is voted as"GA-ready", has the GA-bit turned on, but because of JCP rules is notactually *made* generally available until JSR 220 becomes final. Sincewe all need to vet this release and approve it, it would be available tothe Derby community, but not *generally* available by distributing it onall the Apache mirrors. It would still be easily available. And once downloaded, and probablyredistributed further, downstream users would have no idea that theyaren't working with an official Apache release.As I understand it, this is what happens today. Once the release candidate is announced, anyone can theoretically grab the bits and distribute them before the release is voted on and available from the mirrors. Is this considered a problem today?What is the specific legal verbiage we're working with here?IANAL, but the only license available right now (the license under which the community is using the bits) is an evaluation license for JSR 221, which reads, in part:Subject to the terms and conditions of this license, Sun hereby grants you a fully-paid, non-exclusive, non-transferable, limited license (without the right to sublicense) under Sun's intellectual property rights to review the Specification only for the purposes of evaluation.Until Mustang goes GA, there is no redistribution license available.Craig -jean I know this seems like a fine hair to split, but it's the only way wecan be successful without Sun having to do a non-upgradable fork ofDerby, which I don't think any of us want.I hope this helps to clear things up, even if it doesn't make thingssimpler :)David 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

catch-22: Derby, Mustang, and JCP issue

David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:

 + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
 + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.

Let's keep this thread confined to the JCP issue Andrew raised that to
roll a release candidate qualifies as creation.[2] And those release
candidates will be generally available.

How do we handle this cleanly?

-jean


[1]
http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html
[2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html

Re: catch-22: Derby, Mustang, and JCP issue

Jean T. Anderson wrote:

 David posted a good summary of the legal catch-22 at [1]. But the
 shortest story is:
 
  + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
  + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
 
 Let's keep this thread confined to the JCP issue Andrew raised that to
 roll a release candidate qualifies as creation.[2] And those release
 candidates will be generally available.

I don't think the JCP rules apply since we are not creating an
implementation of JSR221.

I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver
until Mustang goes GA, but that's not the JCP rules that Andrew provided
references to. It would be good to get Lance to expand on what he meant
when he said:

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.

Where does this restriction come from?

Dan.

 
 How do we handle this cleanly?
 
 -jean
 
 
 [1]
 http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html
 [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html

Re: catch-22: Derby, Mustang, and JCP issue

2006-06-22 Thread Brian McCallister



On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes  
final.


Where does this restriction come from?


Until a spec is final I don't see how you can have a certified compliant
implementation of that spec. It might be as easy as not claiming JDBC  
4.0

compliance until *after* JSR-221 is final, than saying, huh, gee whiz,
we pass the TCK!

If the interfaces happen to exist in a release before the spec is final,
well, cool. Folks using them are at risk of the spec changing at the  
last

minute, so I would put bright red warnings around them if they are event
documented before the official release of the spec (not of Derby).

-Brian

Re: catch-22: Derby, Mustang, and JCP issue

Jean T. Anderson wrote:
 David posted a good summary of the legal catch-22 at [1]. But the
 shortest story is:
 
  + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
  + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.
 
 Let's keep this thread confined to the JCP issue Andrew raised that to
 roll a release candidate qualifies as creation.[2] And those release
 candidates will be generally available.
 
 How do we handle this cleanly?
 
 -jean
 
 
 [1]
 http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html
 [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html

I goofed up these URLs and both point to the start of the thread. I
meant to point to these:

[1]
http://www.nabble.com/Re%3A-Proposal-for-10.2-release-schedule-p5003242.html
[2]
http://www.nabble.com/Re%3A-Proposal-for-10.2-release-schedule-p5003602.html

Re: catch-22: Derby, Mustang, and JCP issue

2006-06-22 Thread Geir Magnusson Jr


Daniel John Debrunner wrote:
 Jean T. Anderson wrote:
 
 David posted a good summary of the legal catch-22 at [1]. But the
 shortest story is:

  + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
  + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.

 Let's keep this thread confined to the JCP issue Andrew raised that to
 roll a release candidate qualifies as creation.[2] And those release
 candidates will be generally available.
 
 I don't think the JCP rules apply since we are not creating an
 implementation of JSR221.

How could that be?  Where did the information for the APIs come from?

 
 I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver
 until Mustang goes GA, but that's not the JCP rules that Andrew provided
 references to. It would be good to get Lance to expand on what he meant
 when he said:
 
 You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.
 
 Where does this restriction come from?

I'm not sure.  The license on the public review draft gives no rights to
distribute an implementation under *any* label (more recent public
review draft licenses  do now after the whole EJB3 brouhaha)

 
 Dan.
 
 How do we handle this cleanly?

I would assume that you just don't ship a JDBC 4 driver with the release
of Derby, and do a release when the spec is final and a TCK can be
obtained from the spec lead to ensure that the implementation is
compatible with the spec.

It's just a driver.  The database is fully functional w/o it, right?

Seems to be fairly simple.

geir


 -jean


 [1]
 http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html
 [2] http://www.nabble.com/Proposal-for-10.2-release-schedule-t1832249.html

Re: catch-22: Derby, Mustang, and JCP issue

2006-06-22 Thread Geir Magnusson Jr


Brian McCallister wrote:
 
 On Jun 22, 2006, at 7:09 PM, Daniel John Debrunner wrote:
 
 You cannot have a GA version of a JDBC 4 driver until JSR 221 goes
 final.

 Where does this restriction come from?
 
 Until a spec is final I don't see how you can have a certified compliant
 implementation of that spec. It might be as easy as not claiming JDBC 4.0
 compliance until *after* JSR-221 is final, than saying, huh, gee whiz,
 we pass the TCK!

The only problem I see is that by the letter of the law, there is no
right to implement and distribute JDBC4's public draft.

I guess the first thing to figure out is what from the JDBC4 expert
group has actually been implemented.

 
 If the interfaces happen to exist in a release before the spec is final,
 well, cool.

Sun used to have some strange arguments about spec API copyrights which
made that uncool unless you passed the TCK (which implied completion of
the JSR)

 Folks using them are at risk of the spec changing at the last
 minute, so I would put bright red warnings around them if they are event
 documented before the official release of the spec (not of Derby).

Or just leave JDBC4 out of the GA release, and given it's only a
database driver, just offer it as a second jar when it's possible to do so.

Why tie the DB release cycle to an updated driver?  Won't a JDBC3 driver
work well too?

geir

Re: catch-22: Derby, Mustang, and JCP issue


Brian McCallister wrote:


If the interfaces happen to exist in a release before the spec is final,
well, cool. Folks using them are at risk of the spec changing at the  
last

minute, so I would put bright red warnings around them if they are event
documented before the official release of the spec (not of Derby).


+1
- We have a Derby 10.2 GA release with any JDBC 4.0 functionality marked 
as USE AT YOUR OWN RISK, just part of incremental devlopment and totally 
subject to change if the spec does.

- Mustang takes that and runs with it.
- Then we have a follow up release, yes even two months later where we 
are certified compliant.


A nice clean 2 phase commit.  I haven't read the legal stuff, but does 
this not work?


Kathey

Re: catch-22: Derby, Mustang, and JCP issue

2006-06-22 Thread Geir Magnusson Jr



Kathey Marsden wrote:
 Brian McCallister wrote:
 
 If the interfaces happen to exist in a release before the spec is final,
 well, cool. Folks using them are at risk of the spec changing at the 
 last
 minute, so I would put bright red warnings around them if they are event
 documented before the official release of the spec (not of Derby).

 +1
 - We have a Derby 10.2 GA release with any JDBC 4.0 functionality marked
 as USE AT YOUR OWN RISK, just part of incremental devlopment and totally
 subject to change if the spec does.
 - Mustang takes that and runs with it.
 - Then we have a follow up release, yes even two months later where we
 are certified compliant.
 
 A nice clean 2 phase commit.  I haven't read the legal stuff, but does
 this not work?

It works, but if you want to be technical about it, not really.  Because
of the license Sun chose for the public draft for JDBC4, you can't
actually implement and distribute it.

Of course, as the licensor, Sun could offer a 'clarification' of that
license and allow implementations of the public draft, and that would at
least let us legally ship it.

The cleanest way seem to just remove the JDBC4 stuff from the upcoming
GA release, and then release a JDBC4 driver as fast as you can once you
have the final spec and a TCK.

geir

Re: catch-22: Derby, Mustang, and JCP issue

Geir Magnusson Jr wrote:
 Daniel John Debrunner wrote:
 
Jean T. Anderson wrote:


David posted a good summary of the legal catch-22 at [1]. But the
shortest story is:

 + Mustang wants to ship a GA Derby 10.2, which supports JDBC 4.0.
 + Derby can't ship a GA 10.2 until JDBC 4.0 is GA, which is with Mustang.

Let's keep this thread confined to the JCP issue Andrew raised that to
roll a release candidate qualifies as creation.[2] And those release
candidates will be generally available.

I don't think the JCP rules apply since we are not creating an
implementation of JSR221.
 
 
 How could that be?  Where did the information for the APIs come from?

Isn't an implementation of JSR221 writing (clean room) classes in the
java.sql and javax.sql name spaces. (e.g. java.sql.Driver 
javax.sql.DataSource).

Derby is not doing that, Derby is providing an implementation of a JDBC
driver, not an implementation of JSR221 itself. Implementing JSR221 is
something that Harmony would (might) do.

My point is that the JCP rules for implementation of the spec itself do
not apply here.

I'm sure other rules apply that say one cannot ship a JDBC 4.0 driver
until Mustang goes GA, but that's not the JCP rules that Andrew provided
references to. It would be good to get Lance to expand on what he meant
when he said:

You cannot have a GA version of a JDBC 4 driver until JSR 221 goes final.

Where does this restriction come from?
 
 
 I'm not sure.  The license on the public review draft gives no rights to
 distribute an implementation under *any* label (more recent public
 review draft licenses  do now after the whole EJB3 brouhaha)

My point is implementation of what exactly. I think Lance (JSR221 spec
lead) has already said that the TCK for JSR221 just checks the the
classes (java.sql etc.) exist and have the correct methods  signatures,
that implies to me that implementing JSR221 means providing those classes.

Dan.

Re: catch-22: Derby, Mustang, and JCP issue