[jira] Updated: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading

[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa updated DERBY-1379: - Attachment: autoload.diff This patch solves the problem with running the Nist tests under jdk 1.6 by unloading the embedded driver before the nist suite is

[jira] Updated: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading

[ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa updated DERBY-1379: - Derby Info: [Patch Available] NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading

[jira] Updated: (DERBY-1376) File java/engine/org/apache/derby/loc/messages_en.properties - Message XSLAT.D

[ http://issues.apache.org/jira/browse/DERBY-1376?page=all ] Andrew McIntyre updated DERBY-1376: --- Fix Version: 10.1.2.5 (was: 10.1.2.4) Version: 10.1.3.0 10.1.2.5 (was: 10.1.2.4) File

[jira] Assigned: (DERBY-1253) Verify that we don't raise SQLFeatureNotSupportedException for mandatory methods

[ http://issues.apache.org/jira/browse/DERBY-1253?page=all ] Dyre Tjeldvoll reassigned DERBY-1253: - Assign To: (was: Dyre Tjeldvoll) Verify that we don't raise SQLFeatureNotSupportedException for mandatory methods

Regression Test Failure! - Derby 412466 - Sun DBTG

[Auto-generated mail] *Derby* 412466/2006-06-07 19:46:10 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 141708567 0 118.47% SunOS-5.10_i86pc-i386 Details in

[jira] Updated: (DERBY-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode

[ http://issues.apache.org/jira/browse/DERBY-1295?page=all ] Fernanda Pizzorno updated DERBY-1295: - Attachment: derby-1295v2.diff derby-1295v2.stat I am attaching a new patch (derby-1295v2.diff) addressing the review comments. Can

[jira] Commented: (DERBY-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode

[ http://issues.apache.org/jira/browse/DERBY-1295?page=comments#action_12415306 ] Andreas Korneliussen commented on DERBY-1295: - Patch looks good - I will run some test and commit if successful. Result sets of type TYPE_SCROLL_INSENSITIVE

[jira] Updated: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()

[ http://issues.apache.org/jira/browse/DERBY-501?page=all ] Knut Anders Hatlen updated DERBY-501: - Attachment: derby-501-v3.diff derby-501-v3.stat Committed the new test class in the v2 patch with revision 412711 (to make it easier

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415318 ] Bernt M. Johnsen commented on DERBY-1384: - The maximum value supported by Derby is not 2G, but 2G-1, which the user have to write as 2147483647, which again is pretty

[jira] Assigned: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen reassigned DERBY-1384: --- Assign To: Bernt M. Johnsen Increase default BLOB/CLOB length to maximum supported (2G?)

Re: [jira] Updated: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading

Olav Sandstaa (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1379?page=all ] Olav Sandstaa updated DERBY-1379: - Attachment: autoload.diff This patch solves the problem with running the Nist tests under jdk 1.6 by unloading the embedded

[jira] Created: (DERBY-1387) Add JMX extensions to Derby

Add JMX extensions to Derby --- Key: DERBY-1387 URL: http://issues.apache.org/jira/browse/DERBY-1387 Project: Derby Type: New Feature Reporter: Sanket Sharma Assigned to: Sanket Sharma This is a draft proposal for adding JMX

[jira] Commented: (DERBY-1386) Wrong results with query using LIKE and ESCAPE clause that includes %, \, and _

[ http://issues.apache.org/jira/browse/DERBY-1386?page=comments#action_12415324 ] Knut Anders Hatlen commented on DERBY-1386: --- I see the same results. However, when I use like to test the same values as constants, it correctly evaluates to true:

[jira] Updated: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen updated DERBY-1384: Attachment: derby-1384-code.diff Increase default BLOB/CLOB length to maximum supported (2G?)

[jira] Commented: (DERBY-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode

[ http://issues.apache.org/jira/browse/DERBY-1295?page=comments#action_12415329 ] Andreas Korneliussen commented on DERBY-1295: - Some preliminary testing results: * When running the new test, without the patch, the test failed as expected in

[jira] Updated: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen updated DERBY-1384: Attachment: derby-1384-code.stat Increase default BLOB/CLOB length to maximum supported (2G?)

[jira] Updated: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen updated DERBY-1384: Attachment: derby-1384-docs.diff derby-1384-docs.stat Increase default BLOB/CLOB length to maximum supported (2G?)

[jira] Updated: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen updated DERBY-1384: Fix Version: 10.2.0.0 Derby Info: [Patch Available] Increase default BLOB/CLOB length to maximum supported (2G?)

[jira] Commented: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()

[ http://issues.apache.org/jira/browse/DERBY-501?page=comments#action_12415332 ] Kathey Marsden commented on DERBY-501: -- Might this change affect existing applications? Could you describe any behaviour change that might impact users as it might be

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415335 ] Daniel John Debrunner commented on DERBY-1384: -- I thought 2G can be written (and means 2G -1). Changing the default can change the behaviour of exisitng

[jira] Updated: (DERBY-331) create table fails when a constraint defintion follows a column default

[ http://issues.apache.org/jira/browse/DERBY-331?page=all ] Mayuresh Nirhali updated DERBY-331: --- Fix Version: 10.1.3.0 This bug is 10.1 branch porting candidate for 10.1.3 release. I merged the changes (209842) into my fresh 10.1 branch child. The

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415339 ] Bernt M. Johnsen commented on DERBY-1384: - 2G is 2G, not 2G-1. See ISO/IEC 9075-2:2003 (E) 6.1 data type: If large object length immediately contains large object

[jira] Updated: (DERBY-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode

[ http://issues.apache.org/jira/browse/DERBY-1295?page=all ] Andreas Korneliussen updated DERBY-1295: Attachment: derby-1295v3.diff derby-1295v3.stat Attaching patch derby-1295 with minor update of testcode as commented above.

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415347 ] Andreas Korneliussen commented on DERBY-1384: - Maybe the Release Note Required checkbox should be checked for this change. My understanding is that after an

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415348 ] Daniel John Debrunner commented on DERBY-1384: -- Bernt wrote: 2G is 2G, not 2G-1. See ISO/IEC 9075-2:2003 (E) 6.1 data type: In Derby, at the moment,

[jira] Updated: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()

[ http://issues.apache.org/jira/browse/DERBY-501?page=all ] Knut Anders Hatlen updated DERBY-501: - Derby Info: [Patch Available, Existing Application Impact, Release Note Needed] (was: [Patch Available]) I don't think it is very likely that

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415351 ] Bernt M. Johnsen commented on DERBY-1384: - I admit that to interpret 2G as 2147483647 is user-friendly, but that should be reflected in the docs which currently says

[jira] Updated: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=all ] Bernt M. Johnsen updated DERBY-1384: Derby Info: [Patch Available, Release Note Needed] (was: [Patch Available]) Increase default BLOB/CLOB length to maximum supported (2G?)

[jira] Commented: (DERBY-1301) Improve streaming of large objects for network server and client,from client to server

[ http://issues.apache.org/jira/browse/DERBY-1301?page=comments#action_12415352 ] Tomohito Nakayama commented on DERBY-1301: -- I found there exists two of writeScalarStream methods in org.apache.derby.client.net.Request class. I need to read these

[jira] Created: (DERBY-1388) Integrate processing code of two writeScalarStream methods.

Integrate processing code of two writeScalarStream methods. --- Key: DERBY-1388 URL: http://issues.apache.org/jira/browse/DERBY-1388 Project: Derby Type: Sub-task Reporter: Tomohito Nakayama Reading

[jira] Assigned: (DERBY-1388) Integrate processing code of two writeScalarStream methods.

[ http://issues.apache.org/jira/browse/DERBY-1388?page=all ] Tomohito Nakayama reassigned DERBY-1388: Assign To: Tomohito Nakayama Integrate processing code of two writeScalarStream methods.

[jira] Commented: (DERBY-1388) Integrate processing code of two writeScalarStream methods.

[ http://issues.apache.org/jira/browse/DERBY-1388?page=comments#action_12415355 ] Tomohito Nakayama commented on DERBY-1388: -- My plan is to call writeScalarStream method for InputStream, from that for Reader, with parameter of InputStream object

Feature list for adding JMX extensions to derby

Hi.. Please see the following and the attached file for a list of features that could be added to derby. http://issues.apache.org/jira/browse/DERBY-1387 Awaiting responses Best Regards, Sanket Sharma

Re: [jira] Updated: (DERBY-501) Client and embedded drivers differ on invoking a procedure that returns a single Dynamic resultSet using CallableStatement.executeQuery()

Knut Anders Hatlen (JIRA) wrote: - Derby Info: [Patch Available, Existing Application Impact, Release Note Needed] (was: [Patch Available]) [snip nice summary of behaviour change] Thanks Knut, this is the kind of clear explanation users need.

[jira] Updated: (DERBY-1388) Integrate processing code of two writeScalarStream methods.

[ http://issues.apache.org/jira/browse/DERBY-1388?page=all ] Tomohito Nakayama updated DERBY-1388: - Component: Network Client Description: Reading the two of writeScalarStream methods in org.apache.derby.client.net.Request class, I found that

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

[ http://issues.apache.org/jira/browse/DERBY-1313?page=comments#action_12415363 ] Kathey Marsden commented on DERBY-1313: --- Thanks Dag for the check and the clarification. Fernanda said: This may later be extended for other warnings, but I do not

[jira] Created: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns

IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns -- Key: DERBY-1389 URL:

[jira] Assigned: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns

[ http://issues.apache.org/jira/browse/DERBY-1389?page=all ] V.Narayanan reassigned DERBY-1389: -- Assign To: V.Narayanan IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns

Re: [jira] Assigned: (DERBY-1386) Wrong results with query using LIKE and ESCAPE clause that includes %, \, and _

Knut Anders Hatlen (JIRA) wrote: There is a bug in the unoptimized version of Like.lessThanString(). The bug was not introduced by DERBY-1262, just exposed by it. I will try to fix it in trunk and 10.1. Thank you, Knut, for investigating this failure and replying so quickly. And for

[jira] Updated: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns

[ http://issues.apache.org/jira/browse/DERBY-1389?page=all ] V.Narayanan updated DERBY-1389: --- Attachment: IS_AUTOINCREMENT_v1.diff IS_AUTOINCREMENT_v1.stat Please find the patch attached for this issue. The patch required me to modify the

[jira] Updated: (DERBY-1389) IS_AUTOINCREMENT column should be returned as part of the Database description returned by DatabaseMetaData.getColumns

[ http://issues.apache.org/jira/browse/DERBY-1389?page=all ] V.Narayanan updated DERBY-1389: --- Derby Info: [Patch Available, Release Note Needed] IS_AUTOINCREMENT column should be returned as part of the Database description returned by

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

[ http://issues.apache.org/jira/browse/DERBY-1361?page=comments#action_12415365 ] Andreas Korneliussen commented on DERBY-1361: - It seems to me that it is the store layer which has the knowledge on if a cursor has lost its position as a

Re: Feature list for adding JMX extensions to derby

Sanket Sharma wrote: Hi.. Please see the following and the attached file for a list of features that could be added to derby. http://issues.apache.org/jira/browse/DERBY-1387 Awaiting responses Just a couple of quick comments: 1) quote 4. Assumptions and Dependencies The interfaces follow

[jira] Updated: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=all ] Mamta A. Satoor updated DERBY-1327: --- Attachment: Derby1327WrongStartKeyPatch1CodelineTrunk.txt The fix for this issue would be to reduce the number of parameters required by the constructor

[jira] Assigned: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=all ] Mamta A. Satoor reassigned DERBY-1327: -- Assign To: Mamta A. Satoor Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build

[PATCH}DERBY-1327:Identity column can be created with wrong and very large start with value

Hi, DERBY-1327 can cause system tables to have incorrect start with values for new tables as well as existing tables. The fix for this would be to reduce the number of parameters required by the constructor to =10 in org.apache.derby.iapi.sql.dictionary.ColumnDescriptor class. While researching

[jira] Commented: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12415369 ] Mamta A. Satoor commented on DERBY-1327: BTW, the patch, Derby1327WrongStartKeyPatch1CodelineTrunk.txt is for the main codeline. If it looks good and there are no

[jira] Updated: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=all ] Mamta A. Satoor updated DERBY-1327: --- Derby Info: [Patch Available] Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

[ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12415374 ] David Van Couvering commented on DERBY-1387: Hi, Sanket. Can you re-attach your documents as individual non-compressed files? That makes it a lot easier to

[jira] Updated: (DERBY-1387) Add JMX extensions to Derby

[ http://issues.apache.org/jira/browse/DERBY-1387?page=all ] Sanket Sharma updated DERBY-1387: - Attachment: Requirements for JMX.html Requirements in a single html file. Add JMX extensions to Derby --- Key:

[jira] Updated: (DERBY-1387) Add JMX extensions to Derby

[ http://issues.apache.org/jira/browse/DERBY-1387?page=all ] Sanket Sharma updated DERBY-1387: - Attachment: Requirements for JMX Updated.html Please download this file for JMX requirements. This is the updated version. Add JMX extensions to Derby

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415387 ] Satheesh Bandaram commented on DERBY-1384: -- While I still don't know if this change is good or not for Derby at this time, change in max length, if applied, should

[jira] Commented: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()

[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415389 ] David Van Couvering commented on DERBY-1004: Hi, Deepa, thanks for your review. The problem was I was still getting the error in some cases when I put it

Re: Feature list for adding JMX extensions to derby

The document you are referring to is C Language Style Guide, not Java. I just don't understand why, as there are several Java-specific coding guidelines out there. A couple of them are mentioned here: http://wiki.apache.org/db-derby/DerbyContributorChecklist corrected. Thank you for pointing

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415394 ] Andreas Korneliussen commented on DERBY-1384: - I do not see how the improvement would cause any problems after an downgrade, since it is about changing the

[jira] Created: (DERBY-1390) Statement.setEscapeProcessing() is a NOP in Derby.

Statement.setEscapeProcessing() is a NOP in Derby. -- Key: DERBY-1390 URL: http://issues.apache.org/jira/browse/DERBY-1390 Project: Derby Type: Improvement Components: JDBC Versions: 10.2.0.0 Reporter:

[jira] Resolved: (DERBY-1295) Result sets of type TYPE_SCROLL_INSENSITIVE should not implicitly close due to positioning in autocommit mode

[ http://issues.apache.org/jira/browse/DERBY-1295?page=all ] Andreas Korneliussen resolved DERBY-1295: - Resolution: Fixed Derby Info: [Existing Application Impact, Release Note Needed] (was: [Patch Available, Existing Application

[jira] Updated: (DERBY-1281) JDBC4 Compliance

[ http://issues.apache.org/jira/browse/DERBY-1281?page=all ] Rick Hillegas updated DERBY-1281: - Description: Here is my analysis of where we currently fall short of JDBC4 compliance, based on my reading of the current draft revision of the JDBC4

Request that svn commit comments include the bug summary

I often have to look at the svn history for a checkin range e.g. svn log -r 405803:409283 On the 10.1 branch I see lots of commits with comments like this: DERBY-324 Merged by svn merge -r 232996:232997 ../trunk/ Originally submitted Olav Sandstaa

Re: Feature list for adding JMX extensions to derby

A note that it would be great if these discussions could be maintained as comments on the JIRA. I think including Network Server specific features would be good to include in this document, I don't know why a separate document is needed. There are a lot of valuable features that could be

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415400 ] Sunitha Kambhampati commented on DERBY-1384: Please note: that our interfaces like DataTypeDescriptor.getMaximumWidth() etc currently return an int . Any change

[jira] Commented: (DERBY-1387) Add JMX extensions to Derby

[ http://issues.apache.org/jira/browse/DERBY-1387?page=comments#action_12415402 ] David Van Couvering commented on DERBY-1387: Hi, Sanket, thanks for a very nicely organized and formatted set of requirements! Here are my comments: - In

[jira] Commented: (DERBY-1390) Statement.setEscapeProcessing() is a NOP in Derby.

[ http://issues.apache.org/jira/browse/DERBY-1390?page=comments#action_12415403 ] Rick Hillegas commented on DERBY-1390: -- Lance Andersen clarifies: Hi Rick, I never said non-compliance. As long as the method can be executed, what if anything you

[jira] Closed: (DERBY-1390) Statement.setEscapeProcessing() is a NOP in Derby.

[ http://issues.apache.org/jira/browse/DERBY-1390?page=all ] Rick Hillegas closed DERBY-1390: Resolution: Invalid According to Lance, NOP behavior is compliant. Statement.setEscapeProcessing() is a NOP in Derby.

[jira] Updated: (DERBY-1281) JDBC4 Compliance

[ http://issues.apache.org/jira/browse/DERBY-1281?page=all ] Rick Hillegas updated DERBY-1281: - Description: Here is my analysis of where we currently fall short of JDBC4 compliance, based on my reading of the current draft revision of the JDBC4

[jira] Updated: (DERBY-1329) ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.

[ http://issues.apache.org/jira/browse/DERBY-1329?page=all ] Satheesh Bandaram updated DERBY-1329: - Derby Info: (was: [Patch Available]) Submitted this patch to 10.1 branch. Please resolve and/or close accordingly. ASSERT

Re: Feature list for adding JMX extensions to derby

David Van Couvering wrote: A note that it would be great if these discussions could be maintained as comments on the JIRA. Actually, do we want to maintain discussions in Jira? On other apache lists, I consistently see posts that chase development discussions *off* Jira and back onto the

docs don't appear in snapshots

Hey Andrew, I may have posed this question while you were on vacation: Snapshots don't contain the user docs although releases do. What's the reason for not bundling user guides in snapshots? Thanks, -Rick

Re: Feature list for adding JMX extensions to derby

No, you understood me, and I see what you are saying too. I guess it's a question of making it easy to find out what's going on around a particular feature. I guess you x-ref to a mail thread? I guess I don't have a *strong* preference, I just thought this kind of thing is easier to track

[jira] Commented: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()

[ http://issues.apache.org/jira/browse/DERBY-1004?page=comments#action_12415409 ] Deepa Remesh commented on DERBY-1004: - Hi David, My comment was only based on your previous comment which made me wonder why you did not add the rollback to

Discussions in and out of Jira (was Re: Feature list for adding JMX extensions to derby)

David Van Couvering wrote: No, you understood me, and I see what you are saying too. I guess it's a question of making it easy to find out what's going on around a particular feature. I guess you x-ref to a mail thread? I guess I don't have a *strong* preference, I just thought this kind

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415410 ] Satheesh Bandaram commented on DERBY-1384: -- Here is one situation where changing default max length would cause problem. In soft upgrade, if some one creates a

A quick code convention question

For a class that has an empty constructor and all it's initialization code in the boot() method, is the boot method the appropriate place for initialization which isn't strictly associated with booting the service as well, or is it okay to put an object initalization in the constructor? Case in

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415413 ] Daniel John Debrunner commented on DERBY-1384: -- I would say strictly speaking that this is not a concern for soft-upgrade. The data written to disk (if the

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

[ http://issues.apache.org/jira/browse/DERBY-1271?page=all ] Rick Hillegas updated DERBY-1271: - Description: We can't check in any of this work until we understand how our release trains line up. However, the JDBC4-bearing release will need the

Re: docs don't appear in snapshots

On 6/8/06, Rick Hillegas [EMAIL PROTECTED] wrote: Hey Andrew, I may have posed this question while you were on vacation: Snapshots don't contain the user docs although releases do. What's the reason for not bundling user guides in snapshots? It keeps the download small (conserving bandwidth

Re: docs don't appear in snapshots

Thanks, Andrew. I don't have strong feelings about this issue yet. My internal customers wanted the user guides which went with the executable bits and I found I couldn't just point them at the download page for one-stop-shopping. Regards, -Rick Andrew McIntyre wrote: On 6/8/06, Rick

Re: Discussions in and out of Jira (was Re: Feature list for adding JMX extensions to derby)

Yes, that sounds good. David Jean T. Anderson wrote: David Van Couvering wrote: No, you understood me, and I see what you are saying too. I guess it's a question of making it easy to find out what's going on around a particular feature. I guess you x-ref to a mail thread? I guess I don't

[jira] Resolved: (DERBY-1329) ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.

[ http://issues.apache.org/jira/browse/DERBY-1329?page=all ] A B resolved DERBY-1329: Resolution: Fixed Checked into trunk with svn # 411393 and into 10.1 with svn # 412832. I have verified the fix in both codelines by running the repro and by running

[jira] Closed: (DERBY-1329) ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.

[ http://issues.apache.org/jira/browse/DERBY-1329?page=all ] A B closed DERBY-1329: -- ASSERT failure/IndexOutOfBoundsException with correlated subquery for UPDATE ... SET ... WHERE CURRENT OF ... statement.

[jira] Commented: (DERBY-1379) NIST tests fail on jdk16 after introduction of JDBC4 driver autoloading

[ http://issues.apache.org/jira/browse/DERBY-1379?page=comments#action_12415428 ] Rick Hillegas commented on DERBY-1379: -- An elegant solution. I have confirmed that the nist tests now pass under the problem scenario. Committed at subversion revision

[jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

[ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12415429 ] David Van Couvering commented on DERBY-289: --- Now that the i18n work is pretty much done and the 10.1.3 release is closed, I'd like to revisit our beloved issue of

[jira] Commented: (DERBY-1384) Increase default BLOB/CLOB length to maximum supported (2G?)

[ http://issues.apache.org/jira/browse/DERBY-1384?page=comments#action_12415433 ] Satheesh Bandaram commented on DERBY-1384: -- This is the case I was thinking about. I have coded my application without specifying lengths for BLOB/CLOB. I would

[jira] Resolved: (DERBY-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()

[ http://issues.apache.org/jira/browse/DERBY-1004?page=all ] David Van Couvering resolved DERBY-1004: Fix Version: 10.2.0.0 10.1.3.0 Resolution: Fixed Fixed in trunk, revision 412852. Fixed in 10.1 branch, revision

[jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

[ http://issues.apache.org/jira/browse/DERBY-289?page=comments#action_12415437 ] Rick Hillegas commented on DERBY-289: - A small refinement: I'd like to see the generated files go under a subdirectory parallel to classes and java. The generated subtree

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

Hm, it seems a little odd to have Java classes somewhere other than under java. Doesn't it make it significantly harder to build jar files? Can't the 'clobber' task take care of pruning the 'generated' directory? David Rick Hillegas (JIRA) wrote: [

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

Sorry, silly mental mixup, you don't build jar files from the source tree. But I still think it's odd to have java classes under some other separate tree. But on the other hand it would convey very differently that these classes are different and not part of what you would actually want to

[jira] Updated: (DERBY-1368) EOFException when reading from blob's binary stream

[ http://issues.apache.org/jira/browse/DERBY-1368?page=all ] Sunitha Kambhampati updated DERBY-1368: --- Attachment: Derby1368.java I took the testcase code snippet and ran the program Derby1368 on 10.2.0.3 alpha classes ( 412194) and it works OK

[jira] Resolved: (DERBY-851) Remove org.apache.derby.client.resource package - no longer needed

[ http://issues.apache.org/jira/browse/DERBY-851?page=all ] David Van Couvering resolved DERBY-851: --- Fix Version: 10.2.0.0 Resolution: Fixed Resolved, revision 412888 Remove org.apache.derby.client.resource package - no longer needed

[jira] Resolved: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible

[ http://issues.apache.org/jira/browse/DERBY-254?page=all ] David Van Couvering resolved DERBY-254: --- Resolution: Fixed All client messages have been converted to use SQL States as part of the DERBY-400 work, which is now complete except for

[jira] Updated: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible

[ http://issues.apache.org/jira/browse/DERBY-254?page=all ] David Van Couvering updated DERBY-254: -- Derby Info: [Release Note Needed] Proposed release note on this: In this release, all of the client SQLExceptions now return valid SQL States

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

David Van Couvering (JIRA) wrote: I'd like to revisit our beloved issue of code sharing. [snip details on code sharing proposal that does not negatively impact users. Hooray!] I personally prefer an approach similar to the obfuscation tools, where 1) All the code imports the checked in

[jira] Commented: (DERBY-1349) Document user-visible changes affected by internationalization of the network client

[ http://issues.apache.org/jira/browse/DERBY-1349?page=comments#action_12415454 ] David Van Couvering commented on DERBY-1349: So, what has changed is that all messages are internationalized, and all exceptions contain a valid SQL State. Does

[jira] Reopened: (DERBY-254) SQLStates for SQLExceptions thrown from the client should not be null and should match embedded where possible

[ http://issues.apache.org/jira/browse/DERBY-254?page=all ] David Van Couvering reopened DERBY-254: --- Re-opening pending finalization of the release note text that should go with this change. SQLStates for SQLExceptions thrown from the client

New updates to the Wiki - Should they be here? (was Re: [Db-derby Wiki] Update of LifeCache by DonaldMcLean)

Apache Wiki wrote: Dear Wiki user, You have subscribed to a wiki page or wiki category on Db-derby Wiki for change notification. The following page has been changed by DonaldMcLean: http://wiki.apache.org/db-derby/LifeCache I wonder if this content is really appropriate for the Derby

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

Kathey Marsden wrote: David Van Couvering (JIRA) wrote: I'd like to revisit our beloved issue of code sharing. [snip details on code sharing proposal that does not negatively impact users. Hooray!] I personally prefer an approach similar to the obfuscation tools, where 1) All the code

[jira] Commented: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12415458 ] Satheesh Bandaram commented on DERBY-1327: -- I was reviewing this change and I noticed we are moving this: - /* NOTE: We use the autoincColumn variable

[jira] Commented: (DERBY-1327) Identity column can be created with wrong and very large start with value with J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2) with JIT on

[ http://issues.apache.org/jira/browse/DERBY-1327?page=comments#action_12415460 ] Mamta A. Satoor commented on DERBY-1327: While working on this, I tried looking up the number 4361550 on Sun's website and got only one

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

David Van Couvering wrote: Kathey Marsden wrote: David Van Couvering (JIRA) wrote: I'd like to revisit our beloved issue of code sharing. [snip details on code sharing proposal that does not negatively impact users. Hooray!] I personally prefer an approach similar to the obfuscation

Re: [jira] Commented: (DERBY-289) Enable code sharing between Derby client and engine

David Van Couvering wrote: Kathey. When you say the code is copied and modified as needed what exactly are you thinking of here. Is this byte-code modification, or are you proposing a source-code copy/modify. If the latter, wouldn't this require also modifying all classes depending upon

  1   2   >