[jira] Commented: (DERBY-1513) Trial 1 for DERBY-550
[ http://issues.apache.org/jira/browse/DERBY-1513?page=comments#action_12421379 ] Tomohito Nakayama commented on DERBY-1513: -- However,I found there were difference in behavior. I survey OutOfMemoryError of the program with configuration of -Xmx64m -Xmx128m -Xmx192m -Xmx256m. OutOfMemoryError happen in all of those configurations. However, how OutOfMemoryError was thrown from program was not same between these configurations. Next was information captured by using jdb. -Xmx64m : Exception occurred: java.lang.OutOfMemoryError (uncaught) Exception occurred: java.lang.OutOfMemoryError (uncaught)thread=DRDAConnThread_3, org.apache.derby.impl.drda.DDMReader$MemorySavedByteArrayOutputStream.init(), line=1,807 bci=6 1,807 buf = new byte[size]; DRDAConnThread_3[1] where [1] org.apache.derby.impl.drda.DDMReader$MemorySavedByteArrayOutputStream.init (DDMReader.java:1,807) [2] org.apache.derby.impl.drda.DDMReader.getExtData (DDMReader.java:958) [3] org.apache.derby.impl.drda.DDMReader.getExtData (DDMReader.java:944) [4] org.apache.derby.impl.drda.DRDAConnThread.readAndSetExtParam (DRDAConnThread.java:4,355) [5] org.apache.derby.impl.drda.DRDAConnThread.readAndSetAllExtParams (DRDAConnThread.java:4,320) [6] org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTTobjects (DRDAConnThread.java:3,811) [7] org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT (DRDAConnThread.java:3,640) [8] org.apache.derby.impl.drda.DRDAConnThread.processCommands (DRDAConnThread.java:928) [9] org.apache.derby.impl.drda.DRDAConnThread.run (DRDAConnThread.java:254) DRDAConnThread_3[1] eval java.lang.Runtime.getRuntime().maxMemory() java.lang.Runtime.getRuntime().maxMemory() = 66650112 -Xmx128m : Exception occurred: java.lang.OutOfMemoryError (to be caught at: org.apache.derby.impl.store.raw.data.StoredPage.logRow(), line=4,209 bci=1,370)thread=DRDAConnThread_3, org.apache.derby.iapi.services.io.DynamicByteArrayOutputStream.expandBuffer(), line=243 bci=64 243 byte[] newbuf = new byte[newsize]; DRDAConnThread_3[1] where [1] org.apache.derby.iapi.services.io.DynamicByteArrayOutputStream.expandBuffer (DynamicByteArrayOutputStream.java:243) [2] org.apache.derby.iapi.services.io.DynamicByteArrayOutputStream.write (DynamicByteArrayOutputStream.java:88) [3] java.io.DataOutputStream.write (DataOutputStream.java:85) [4] org.apache.derby.iapi.types.SQLBinary.writeExternal (SQLBinary.java:282) [5] org.apache.derby.impl.store.raw.data.StoredPage.logColumn (StoredPage.java:6,255) [6] org.apache.derby.impl.store.raw.data.StoredPage.logRow (StoredPage.java:3,965) [7] org.apache.derby.impl.store.raw.data.InsertOperation.writeOptionalDataToBuffer (InsertOperation.java:369) [8] org.apache.derby.impl.store.raw.data.InsertOperation.init (InsertOperation.java:114) [9] org.apache.derby.impl.store.raw.data.LoggableActions.actionInsert (LoggableActions.java:138) [10] org.apache.derby.impl.store.raw.data.BasePage.insertNoOverflow (BasePage.java:664) [11] org.apache.derby.impl.store.raw.data.BasePage.insertAtSlot (BasePage.java:585) [12] org.apache.derby.impl.store.raw.data.StoredPage.insertAtSlot (StoredPage.java:6,735) [13] org.apache.derby.impl.store.raw.data.BasePage.insert (BasePage.java:691) [14] org.apache.derby.impl.store.access.heap.HeapController.doInsert (HeapController.java:254) [15] org.apache.derby.impl.store.access.heap.HeapController.insert (HeapController.java:573) [16] org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow (RowChangerImpl.java:447) [17] org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore (InsertResultSet.java:995) [18] org.apache.derby.impl.sql.execute.InsertResultSet.open (InsertResultSet.java:522) [19] org.apache.derby.impl.sql.GenericPreparedStatement.execute (GenericPreparedStatement.java:357) [20] org.apache.derby.impl.jdbc.EmbedStatement.executeStatement (EmbedStatement.java:1,181) [21] org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement (EmbedPreparedStatement.java:1,512) [22] org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute (EmbedPreparedStatement.java:1,190) [23] org.apache.derby.impl.drda.DRDAStatement.execute (DRDAStatement.java:556) [24] org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLSTT (DRDAConnThread.java:3,655) [25] org.apache.derby.impl.drda.DRDAConnThread.processCommands (DRDAConnThread.java:928) [26] org.apache.derby.impl.drda.DRDAConnThread.run (DRDAConnThread.java:254) DRDAConnThread_3[1] eval java.lang.Runtime.getRuntime().maxMemory() java.lang.Runtime.getRuntime().maxMemory() = 133234688 -Xmx192m : Exception occurred: java.lang.OutOfMemoryError (to be caught at: org.apache.derby.impl.store.raw.data.StoredPage.logRow(), line=4,209 bci=1,370)thread=DRDAConnThread_3, org.apache.derby.impl.store.raw.data.MemByteHolder.init(), line=68
[jira] Commented: (DERBY-1513) Trial 1 for DERBY-550
[ http://issues.apache.org/jira/browse/DERBY-1513?page=comments#action_12421381 ] Tomohito Nakayama commented on DERBY-1513: -- Seeing those informations, OutOfMemoryError happens from NetworkServer only in the configuration of -Xmx64m. In other configurations, OutOfMemoryError happens from Engine. I'm not sure what this means yet. I remember that some report says that OutOfMemoryError happens only when NetworkServer/Client were used and does not happen when just Engine was used. Now I suspect that NetworkServer may use Engine inefficiently in the view of memory usage Trial 1 for DERBY-550 - Key: DERBY-1513 URL: http://issues.apache.org/jira/browse/DERBY-1513 Project: Derby Issue Type: Sub-task Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1513.patch, DERBY-1513_2.patch, DERBY-1513_3.patch, serverMemoryUsage.xls, serverMemoryUsage_3.xls http://issues.apache.org/jira/browse/DERBY-550#action_12421280 http://issues.apache.org/jira/browse/DERBY-550#action_12421282 -- 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
Regression Test Failure! - Derby 422273 - Sun DBTG
[Auto-generated mail] *Derby* 422273/2006-07-15 19:46:10 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 13723710 0 104.34% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-422273.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/422273.html *Jvm: 1.5* NA NA NANA CYGWIN_NT-5.1_i686-unknown 9679670 2 117.58% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 7679672 2 106.04% Linux-2.6.9-34.ELsmp_x86_64-x86_64 12679667 2 178.43% SunOS-5.10_i86pc-i386 NA NA NANA SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 NA NA NANA SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-422273.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/422273.html *Jvm: 1.4* NA NA NANA CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 7673666 4 105.24% Linux-2.6.9-34.ELsmp_x86_64-x86_64 9673664 4 211.58% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-422273.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/422273.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/422273.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Updated: (DERBY-323) Locale problem in test of derby
Myrna van Lunteren [EMAIL PROTECTED] writes: On 7/14/06, Knut Anders Hatlen (JIRA) derby-dev@db.apache.org wrote: [snip] The failing tests are: i18n/urlLocale.sql i18n/messageLocale.sql i18n/iepnegativetests_ES.sql All the failures are caused by non-ascii characters that are printed as '?' because they don't exist in the default character set for the locale. I believe this could be fixed by a combination of running the i18n tests with -Dfile.encoding=something and specifying encoding to streams/readers in RunTest. I think those three failures fall under 'my' favorite DERBY-244. Would you like to take it? :-) I've been sitting on it without much progress for a long, long time, just so it doesn't slip off my radar. Thanks, I didn't know they had a JIRA. I'll take a look at it. -- Knut Anders
[jira] Assigned: (DERBY-323) Locale problem in test of derby
[ http://issues.apache.org/jira/browse/DERBY-323?page=all ] Knut Anders Hatlen reassigned DERBY-323: Assignee: Knut Anders Hatlen Locale problem in test of derby --- Key: DERBY-323 URL: http://issues.apache.org/jira/browse/DERBY-323 Project: Derby Issue Type: Bug Components: Test Environment: Japanese localed Windows using cygwiin Reporter: Tomohito Nakayama Assigned To: Knut Anders Hatlen Attachments: derby-323-v1.diff, derby-323-v1.stat Many of derbyall fails at Japanese localed Windows when environment corresponding derbyLocale_JP.jar exists in CLASSPATH. Almost all of derby_all was failed because all result message was generated in Japanese , and that was different from master file. I tried next configuration ... conf_0:Exclude derbyLocale_jp.jar conf_1:Add option -Duser.language=en -Duser.country=US conf_2:Add option -Djvmflags=-Duser.language=en -Duser.country=US conf_3:Defiine environment variable _JAVA_OPTIONS=:-Duser.language=en -Duser.locale=us conf_4:Defiine environment variable LC_CTYPE:en_US conf_0 works well on derbyall suite but some of derbynetclientmats/derbynetmats in derbyall suite was failed. Network module seems to have localed message in other resource. conf_1 works on derbynetclientsmats suite, but same configuration for derbyall suite does not work at all. conf_2 does not work on derbynetclientsmats suite. conf_3 seems to work for locale problem but Picked up _JAVA_OPTIONS: message cause error in test. conf_4 does not works ... Now conf_0 seems to be reasonable method now. I think conf_3 may be reasonable direction to modify test suite. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-244) with linux, depending on env setting $LANG and console encoding, some i18n tests fail
[ http://issues.apache.org/jira/browse/DERBY-244?page=all ] Knut Anders Hatlen reassigned DERBY-244: Assignee: Knut Anders Hatlen (was: Myrna van Lunteren) I am stealing this bug from Myrna. ;) with linux, depending on env setting $LANG and console encoding, some i18n tests fail - Key: DERBY-244 URL: http://issues.apache.org/jira/browse/DERBY-244 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.1.1.0 Environment: Linux, with console.encoding *not* UTF-8 Reporter: Myrna van Lunteren Assigned To: Knut Anders Hatlen Priority: Minor The tests i18n/messageLocale.sql i18n/urlLocale.sql i18n/iepnegativetests_ES.sql will fail on Linux if $LANG and as a result, console.encoding is not set in the same way as when the test master was created. The behavior is that some characters are not seen as outside the ANSI range and are displayed as a ?. Result is as master when $LANG is en_US.UTF-8 But then ieptest.sql will fail which will with ibm142 which pass if $LANG is en_US. This needs some further analysis, so this description may need to be updated later. Whatever the solution is, will need to work for all situations. -- 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-1514) Failures in derbyall in trunk seen after revision 421960
[ http://issues.apache.org/jira/browse/DERBY-1514?page=comments#action_12421441 ] Knut Anders Hatlen commented on DERBY-1514: --- There were two new checkins in that run of the tinderbox test: DERBY-550 and DERBY-836. Since the 550 checkin only updated a comment, I believe the failures are caused by DERBY-836. Failures in derbyall in trunk seen after revision 421960 Key: DERBY-1514 URL: http://issues.apache.org/jira/browse/DERBY-1514 Project: Derby Issue Type: Test Components: Regression Test Failure Affects Versions: 10.2.0.0 Reporter: Deepa Remesh List of failures seen in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/testlog/SunOS-5.10_i86pc-i386/421960-derbyall_diff.txt: derbyall/storeall/storeall.fail:store/testsqldecimal.sql derbyall/storeall/storeall.fail:store/backupRestore.sql derbyall/storeall/storeall.fail:store/onlineBackupTest4.sql /derbyall.fail:nist/dml076.sql /derbyall.fail:nist/dml034.sql /derbyall.fail:nist/dml026.sql /derbyall.fail:nist/dml099.sql /derbyall.fail:nist/dml148.sql In the above failures, store/onlineBackupTest4.sql seems to be intermittent and not seen in the next test run. -- 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-1492) Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa
[ http://issues.apache.org/jira/browse/DERBY-1492?page=all ] Bryan Pendleton updated DERBY-1492: --- Attachment: alterColumnNotNull_1.diff Attached is alterColumnNotNull_1.diff. This patch proposal merges the db2AlterColumn and columnAlterClause routines in the parser into a single routine to handle all the ALTER TABLE ALTER COLUMN variants. Note that the parser changes in this diff are identical to the parser changes in DERBY-1491; the only difference is in the altertable.sql tests. Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa Key: DERBY-1492 URL: http://issues.apache.org/jira/browse/DERBY-1492 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Attachments: alterColumnNotNull_1.diff Allow an existing column in an existing table to be changed from NULL to NOT NULL, or vice versa. Probably the syntax for this should be some variant on the ALTER TABLE statement. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-119) Add ALTER TABLE option to change column from NULL to NOT NULL
[ http://issues.apache.org/jira/browse/DERBY-119?page=all ] Bryan Pendleton reassigned DERBY-119: - Assignee: Bryan Pendleton Add ALTER TABLE option to change column from NULL to NOT NULL - Key: DERBY-119 URL: http://issues.apache.org/jira/browse/DERBY-119 Project: Derby Issue Type: New Feature Components: SQL Reporter: Bernd Ruehlicke Assigned To: Bryan Pendleton There was a thread about this on the Cloudscape forum http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?message=4103269cat=19thread=59941forum=370#4103269 Since this describes the problem I will just copy the content of this entry as my dexscription The content of this was Hi, I stumbled across a behaviour of cloudscape which is not a bug but IMHO an implementation choice. To assign a primary key to a table using ALTER TABLE all columns must be declared NOT NULL first, which can only be specified upon column creation (no ALTER TABLE statement exists to change the NOT NULL property of a column). Most databases I know do two things differently: 1) when a primary key is assigned all pk columns are automatically set to NOT NULL, if one of them contains NULL values, the ALTER TABLE statement fails 2) it is possible to alter the column to set the NOT NULL property after column creation (fails when there are already records containing NULL values) If I have understood the limitations correctly in Cloudscape I have no choice but to remove and re-add the column which is supposed to be used in the primary key, if it is not already declared as NOT NULL. This means that in the case of a table containing valid data (unique and not null) in the column in all records, I would have to export the data, remove and re-add the column and reimport that data, which would not be necessary e.g. in Oracle or MaxDB. Is it possible to change that behaviour or is there a good reason for it? It looks as if it makes the life of the user more difficult than necessary for certain metadata manipulations. Making it possible to alter the NOT NULL property of a column would solve this and IMHO having a primary key constraint do this implicitly makes sense as well. Thanks in advance for any insight on this, Robert -- 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-119) Add ALTER TABLE option to change column from NULL to NOT NULL
[ http://issues.apache.org/jira/browse/DERBY-119?page=all ] Bryan Pendleton updated DERBY-119: -- Attachment: alterColumnNotNull_1.diff Attached is alterColumnNotNull_1.diff, a proposed patch which merges the db2AlterColumn and columnAlterClause routines in the parser to provide a single ALTER TABLE ALTER COLUMN statement that provides support for changing the NULL/NOT NULL constraint on a column in a table. Add ALTER TABLE option to change column from NULL to NOT NULL - Key: DERBY-119 URL: http://issues.apache.org/jira/browse/DERBY-119 Project: Derby Issue Type: New Feature Components: SQL Reporter: Bernd Ruehlicke Assigned To: Bryan Pendleton Attachments: alterColumnNotNull_1.diff There was a thread about this on the Cloudscape forum http://www-106.ibm.com/developerworks/forums/dw_thread.jsp?message=4103269cat=19thread=59941forum=370#4103269 Since this describes the problem I will just copy the content of this entry as my dexscription The content of this was Hi, I stumbled across a behaviour of cloudscape which is not a bug but IMHO an implementation choice. To assign a primary key to a table using ALTER TABLE all columns must be declared NOT NULL first, which can only be specified upon column creation (no ALTER TABLE statement exists to change the NOT NULL property of a column). Most databases I know do two things differently: 1) when a primary key is assigned all pk columns are automatically set to NOT NULL, if one of them contains NULL values, the ALTER TABLE statement fails 2) it is possible to alter the column to set the NOT NULL property after column creation (fails when there are already records containing NULL values) If I have understood the limitations correctly in Cloudscape I have no choice but to remove and re-add the column which is supposed to be used in the primary key, if it is not already declared as NOT NULL. This means that in the case of a table containing valid data (unique and not null) in the column in all records, I would have to export the data, remove and re-add the column and reimport that data, which would not be necessary e.g. in Oracle or MaxDB. Is it possible to change that behaviour or is there a good reason for it? It looks as if it makes the life of the user more difficult than necessary for certain metadata manipulations. Making it possible to alter the NOT NULL property of a column would solve this and IMHO having a primary key constraint do this implicitly makes sense as well. Thanks in advance for any insight on this, Robert -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DERBY-1492) Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa
[ http://issues.apache.org/jira/browse/DERBY-1492?page=all ] Bryan Pendleton closed DERBY-1492. -- Resolution: Duplicate Assignee: Bryan Pendleton I mistakenly opened this issue. It is a duplicate of DERBY-119. Provide ALTER TABLE functionality to change a column from NULL to NOT NULL or vice versa Key: DERBY-1492 URL: http://issues.apache.org/jira/browse/DERBY-1492 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.3.1 Reporter: Bryan Pendleton Assigned To: Bryan Pendleton Attachments: alterColumnNotNull_1.diff Allow an existing column in an existing table to be changed from NULL to NOT NULL, or vice versa. Probably the syntax for this should be some variant on the ALTER TABLE statement. -- 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-1515) Provide ALTER TABLE functionality to change a column's data type
Provide ALTER TABLE functionality to change a column's data type Key: DERBY-1515 URL: http://issues.apache.org/jira/browse/DERBY-1515 Project: Derby Issue Type: New Feature Components: Documentation, SQL Affects Versions: 10.1.3.1, 10.1.2.1, 10.1.1.0, 10.2.0.0 Reporter: Bryan Pendleton Priority: Minor Derby should provide a feature which allows a user to change the data type of an existing column in an existing table. Currently, there exists the statement: ALTER TABLE tablename ALTER COLUMN columnname SET DATA TYPE datatype However, this statement currently only allows increasing the length of a VARCHAR column. You are not allowed to decrease the width or to change the data type. It would be nice if this restriction could be lifted, and the datatype could be changed. -- 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-396) Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN
[ http://issues.apache.org/jira/browse/DERBY-396?page=comments#action_12421453 ] Bryan Pendleton commented on DERBY-396: --- I got confused and opened DERBY-1492 accidentally; it was a duplicate of DERBY-119 so I closed it. Then I opened DERBY-1515 to track changing a column's datatype. Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN -- Key: DERBY-396 URL: http://issues.apache.org/jira/browse/DERBY-396 Project: Derby Issue Type: New Feature Components: SQL Environment: LINUX Reporter: Kumar Matcha Assigned To: Bryan Pendleton Attachments: dropColumn_1.diff Alter Statement should support dropping a column, modifying a column to a different data type , rename a column. -- 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-396) Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN
[ http://issues.apache.org/jira/browse/DERBY-396?page=comments#action_12421465 ] Kathey Marsden commented on DERBY-396: -- Since this issue has 14 votes, I think I would prefer to see it left open and the other issues linked as part of this one. That way the vote information can be preserved until the complete issue is resolved. Support for ALTER STATEMENT to DROP , MODIFY, RENAME a COLUMN -- Key: DERBY-396 URL: http://issues.apache.org/jira/browse/DERBY-396 Project: Derby Issue Type: New Feature Components: SQL Environment: LINUX Reporter: Kumar Matcha Assigned To: Bryan Pendleton Attachments: dropColumn_1.diff Alter Statement should support dropping a column, modifying a column to a different data type , rename a column. -- 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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Inconsistent behavior for getBytes and getSubString for embedded versus network
---
Key: DERBY-1516
URL: http://issues.apache.org/jira/browse/DERBY-1516
Project: Derby
Issue Type: Bug
Reporter: Craig Russell
Priority: Minor
org.apache.derby.client.am.Clob.getSubString(pos, length) and
org.apache.derby.client.am.Blob.getBytes(pos, length) check the length for less
than zero.
if ((pos = 0) || (length 0)) {
throw new SqlException(agent_.logWriter_, Invalid position +
pos + or length + length);
But org.apache.derby.impl.jdbc.EmbedClob(pos, length) and
org.apache.derby.impl.jdbc.EmbedBlob(pos, length) check the length for less
than or equal to zero.
if (length = 0)
throw Util.generateCsSQLException(
SQLState.BLOB_NONPOSITIVE_LENGTH, new Integer(length));
The specification does not disallow length of zero, so zero length should be
allowed. I believe that the implementation in org.apache.derby.client.am is
correct, and the implementation in org.apache.derby.impl.jdbc is incorrect.
--
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: Question about DRDAProtocolExceptionInfo fields.
Sunitha Kambhampati [EMAIL PROTECTED] writes: DRDAProtocolExceptionInfo has 4 fields. The comments are unclear to me. Does anyone know what is the difference between the errorCodePoint and the errCdCodePoint ? I'm just guessing here, but it seems to me that errorCodePoint specifies the code point of the error reply message, whereas errCdCodePoint specifies the code point of an extra required field in that reply message. Most error reply messages have one or two required fields that are quite common, like SVRCOD (severity code) or RDBNAM (database name). Some error reply messages additionally have required fields that are specific to them. errCdCodePoint is used to specify these. For instance, SYNTAXRM has a required field called SYNERRCD, and PRCCNVRM has a required field called PRCCNVCD. All the places this object is created, the errCdCodePoint has value NO_ASSOC_ERRCD. Actually, you have these two well hidden in DRDAProtocolException.java: errorInfoTable.put(DRDA_Proto_PRCCNVRM, new DRDAProtocolExceptionInfo( CodePoint.PRCCNVRM, CodePoint.SVRCOD_ERROR, CodePoint.PRCCNVCD, false)); errorInfoTable.put(DRDA_Proto_SYNTAXRM, new DRDAProtocolExceptionInfo( CodePoint.SYNTAXRM, CodePoint.SVRCOD_ERROR, CodePoint.SYNERRCD, true)); -- Knut Anders
Re: [jira] Updated: (DERBY-1373) Encrypted databases cannot be booted using the jar subprotocol (and possibly also using http/https/classpath)
Sunitha Kambhampati (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1373?page=all ] Sunitha Kambhampati updated DERBY-1373: --- Attachment: derby1373.diff.txt derby1373.stat.txt Mathias wrote: I had a look to the suggestion Suresh made.This is a change I do not have time to implement as it would mean revalidate all other cases which are currently working. So I followed up on Suresh's suggestion and am attaching a patch 'derby1373.diff.txt' and 'derby1373.stat.txt' for review. This patch makes the following changes: 1) Instead of using RandomAccessFile, the verifyKey.dat is read as a InputStream. 2) Add a new test (encryptionKey_jar.sql) for booting encrypted database using encryptionKey via classpath, and jar subprotocol. Please note, as already mentioned in an earlier comment - There are existing test (encryptionKey.sql) that test cases for encryptionKey. The test will fail without the code change, and will pass with the code changes. svn stat M java\engine\org\apache\derby\impl\services\jce\JCECipherFactory.java M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant A java\testing\org\apache\derbyTesting\functionTests\tests\store\encryptionKey_jar.sql A java\testing\org\apache\derbyTesting\functionTests\tests\store\encryptionKey_jar_app.properties A java\testing\org\apache\derbyTesting\functionTests\master\encryptionKey_jar.out M java\testing\org\apache\derbyTesting\functionTests\suites\encryptionAll.runall I ran derbyall on ibm142 on linux ok. I made one small change to a comment in the test after that. I have run the test again and it passed ok. Can someone please review this patch. Thanks to Mathias for finding the problem, reporting it, providing a fix and for the good discussion that followed on this issue. If you have the time, it would be nice if you can verify if this works for you. Hi, I'm really sorry for not being more active on this issue lately, I've been kept busy by other (more urgent) stuff. I'll try to test the provided patch on our setup, it should be rather simple to do. I'll keep you updated on the results. Thank you very much for your work, and once again sorry for not helping out much. Regards, Mathias. smime.p7s Description: S/MIME Cryptographic Signature
[jira] Created: (DERBY-1517) Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers
Derby Network Client to handle list of SECMEC(s) returned by existing/released DRDA Derby Network Servers - Key: DERBY-1517 URL: http://issues.apache.org/jira/browse/DERBY-1517 Project: Derby Issue Type: Bug Components: Network Client Environment: The Derby network client should be made capable of handling a list of SECMEC(s) returned by previously released DRDA Derby network servers Reporter: Francois Orsini Fix For: 10.2.0.0 Currently, the Derby DRDA network server does not *properly* return the list of SECMEC(s) it can support if a client is requesting to authenticate with a non-supported SECMEC (see JIRA-926 - http://issues.apache.org/jira/browse/DERBY-926) The motivation for this JIRA is to add the logic for the Derby client to be capable of parsing the list of supported SECMEC(s) returned by previous released Derby network servers (pre-JIRA-926 Fix) - This is necessary for backwards compatibility with older servers - This issue has been even more visible as Derby-528 introduces support for a new DRDA security mechanism (Strong Password Substitute), which causes a DRDA protocol exception when trying to authenticate with the new supported mechanism against older Derby DRDA servers (JIRA-926 issue) JIRA-926 has to be fixed nonetheless on the server side to properly return the list of supported SECMEC(s) in conformance with the DRDA (DDM) specs - This JIRA focuses on the client side to do its best and be capable of parsing a list of SECMEC(s) returned pre-926 fix. Ultimately, the derby network client can be made capable of parsing a list of SECMEC(s) from pre-926 fixed (older) and post-926 fixed servers... -- 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-1518) EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0)
EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0) -- Key: DERBY-1518 URL: http://issues.apache.org/jira/browse/DERBY-1518 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.1.3.1 Reporter: Brian Bonner Are there any plans to implement this functionality? -- 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-1518) EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0)
[ http://issues.apache.org/jira/browse/DERBY-1518?page=comments#action_12421477 ] Brian Bonner commented on DERBY-1518: - It appears that the hibernate folks have modified the DerbyDialect to use a TableHiLoGenerator as the native identity generator in lieu of the IdentityGenerator to circumvent this problem. I've posted a question on their JIRA here: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1915 EmbedConnection prepareStatement(String, String[]) throws not implemented (JDBC 3.0) -- Key: DERBY-1518 URL: http://issues.apache.org/jira/browse/DERBY-1518 Project: Derby Issue Type: Improvement Components: JDBC Affects Versions: 10.1.3.1 Reporter: Brian Bonner Are there any plans to implement this functionality? -- 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-1516) Inconsistent behavior for getBytes and getSubString for embedded versus network
Craig Russell (JIRA) wrote: Inconsistent behavior for getBytes and getSubString for embedded versus network --- Thanks Craig for filing this. Give yourself a point!
[jira] Updated: (DERBY-982) sysinfo api does not provide genus name for client
[ http://issues.apache.org/jira/browse/DERBY-982?page=all ] Andrew McIntyre updated DERBY-982: -- Attachment: derby-982-v4.diff Helps to read the javadoc. From the doc for PipedReader: Attempting to use both objects from a single thread is not recommended, as it may deadlock the thread. And that's what was happening on my machine. So, attaching updated patch which spawns a new thread to read the information from sysinfo.getInfo(), and reads and verifies the first line. Not a great test, but better than nothing. If there is no negative feedback, I plan to commit this patch 7/18 or 7/19. sysinfo api does not provide genus name for client -- Key: DERBY-982 URL: http://issues.apache.org/jira/browse/DERBY-982 Project: Derby Issue Type: Bug Components: Tools Affects Versions: 10.1.2.1 Reporter: Kathey Marsden Assigned To: Andrew McIntyre Fix For: 10.2.0.0 Attachments: derby-982-v4.diff, derby-982.diff, derby-982_v2.diff, derby-982_v3.diff The sysinfo api does not provide access to the genus name for client to allow applications to retrieve information from sysinfo about the client information. http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html Note: Currently ProductGenusNames has a genus name for network server but network server is closely tied to the engine so should always have the same version. -- 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-883) Enhance GROUP BY clause to support expressions instead of just column references.
[ http://issues.apache.org/jira/browse/DERBY-883?page=all ] Manish Khettry updated DERBY-883: - Attachment: 883.patch.txt Enhance GROUP BY clause to support expressions instead of just column references. - Key: DERBY-883 URL: http://issues.apache.org/jira/browse/DERBY-883 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.2.1 Environment: JDK 1.5.0_05 Reporter: Lluis Turro Assigned To: Manish Khettry Attachments: 883.patch.txt This select would return an error syntax on finding ( after month if group by clause: select idissue, month(creation), year(creation), count(distinct idissue) where group by idissue, month(creation), year(creation) -- 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-883) Enhance GROUP BY clause to support expressions instead of just column references.
[ http://issues.apache.org/jira/browse/DERBY-883?page=all ] Manish Khettry updated DERBY-883: - Derby Info: [Patch Available] Functionally, this patch supports expressions in the group by list. An expression in the group by list can also be used in the select list. For example if the grouping expression is c1+c2, then a valid expression in the select list would be c1+c2+1. The expression matching facility is not smart enough to allow c1+1+c2. This patch does not allow the use of grouping expressions in the having clause or order by clause. These are restrictions for now which should be removed eventually. For more information on group by expressions: http://www.pdc.kth.se/doc/SP/manuals/db2-5.0/html/db2s0/db2s0176.htm#HDRGRPBY Another change has been to allow the use of duplicate grouping expressions: i.e select a, sum(b) from test group by a,a; Error messages have been changed. The most noticeable change is the use of the more general sql exception: LANG_INVALID_GROUPED_SELECT_LIST. VerifyAggregateExpressionsVisitor o disallows java nodes. This should take care of functions in java. o the skipChildren method doesn't traverse a subtree that contains any grouping expression. o the error messages are more appropriate-- LANG_INVALID_GROUPED_SELECT_LIST. SelectNode o calls preprocess on the group by list. This is needed because expressions can get rewritten in the select list but not in the grouping list causing problems when the result set is generated. GroupByNode o changes to init() take care of the case where gropuing expressions is not a column reference. o the rewrite logic is a bit different now. Earlier, we would change each unaggregate ColumnReference in the select list and point it to the GroupByColumn. Now we replace each group by expression that we find in the projection list with a virtual column node that effectively points to a result column in the result set doing the group by. In addition the original routine which did the rewrite is now split up into two separate and smaller routines: addUnAggColumns and addAggregateColumns. GroupByColumn o now uses a ValueNode instead of a ColumnReference. Unused methods zapped. GroupByDiff o verifyUniqueGroupingColumn discarded. This was a restriction earlier and it does not make sense. o findGroupingColumn now does the hard work of finding a group by column for a given expression. sqlgrammer o use additiveExpression instead of columnReference. GroupByExpressionTest.java o JUnit test case for this functionality. Enhance GROUP BY clause to support expressions instead of just column references. - Key: DERBY-883 URL: http://issues.apache.org/jira/browse/DERBY-883 Project: Derby Issue Type: New Feature Components: SQL Affects Versions: 10.1.2.1 Environment: JDK 1.5.0_05 Reporter: Lluis Turro Assigned To: Manish Khettry Attachments: 883.patch.txt This select would return an error syntax on finding ( after month if group by clause: select idissue, month(creation), year(creation), count(distinct idissue) where group by idissue, month(creation), year(creation) -- 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-1493) EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String)
[ http://issues.apache.org/jira/browse/DERBY-1493?page=all ] V.Narayanan updated DERBY-1493: --- Attachment: DERBY-1493_v2.diff DERBY-1493_v2.stat Hi, Thanx a ton for the detailed reviews and comments. Attached patch addressing issues with previous. thanx Narayanan EmbeddedDriver does not implement PreparedStatement.setNull(int, int, String) - Key: DERBY-1493 URL: http://issues.apache.org/jira/browse/DERBY-1493 Project: Derby Issue Type: Bug Components: JDBC Affects Versions: 10.2.0.0 Reporter: Knut Anders Hatlen Assigned To: V.Narayanan Attachments: DERBY-1493_v1.diff, DERBY-1493_v1.stat, DERBY-1493_v2.diff, DERBY-1493_v2.stat The embedded driver throws Util.notImplemented() when PreparedStatement.setNull(int, int, String) is called. The javadoc says that [if] the parameter does not have a user-defined or REF type, the given typeName is ignored. The client driver correctly ignores typeName and forwards the call to setNull(int, int). Embedded should be changed to match the client. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-1217) ij should default to protocol 'jdbc:derby:' if no protocol is passed in through ij.protocol
[ http://issues.apache.org/jira/browse/DERBY-1217?page=all ] Andrew McIntyre updated DERBY-1217: --- Attachment: derby-1217-pre.diff Attaching preliminary patch to set the default protocol for ij to jdbc:derby: This allows a user to not set the system property ij.protocol, and connect to an embedded Derby db by default. This is meant for discussion only. This allows you to do the following in ij, if network server is running: connect 'mydb;create=true'; -- //embedded create table t1 (i1 int); insert into t1 values (1); select * from t1; connect 'jdbc:derby://localhost/mydb2;create=true'; create table t1 (i1 int, i2 int); insert into t1 values (1, 2); select * from t1; set connection CONNECTION0; select * from t1; -- // shows the one column from the embedded db set connection CONNECTION1; select * from t1; -- // shows the two columns from network server I haven't checked the behavior w/r/t to J2ME and datasources but from inspection of the code, I don't think they are affected. Also, any negative effect w/r/t/ J2ME could be handled as a part of DERBY-1218. which is related to this issue. The intended effect is that in a simple scenario, with derby embedded, one could connect to one or more databases without needing to know the JDBC URL syntax. This is intended as an ease-of-development feature for ij. If it turns out to be seriously problematic in some environment, we should probably close this bug as Won't Fix. However, initial discussion of this issue seemed encouraging: http://www.nabble.com/default-ij-protocol-%28was-Re%3A--WWD--review-suspended%29-t1182541.html#a3113134 Runs of derbylang and derbytools look encouraging. However, i have not yet tested this patch with ij and databases whose URL does not begin with 'jdbc:'. There is a potential for problem in that case, so I would appreciate it if others could take a look at the patch and provide feedback. Any feedback as to whether this would be useful or not would be great. There i clearly some doc impact if we decide to go this route. Opinions, thoughts? andrew ij should default to protocol 'jdbc:derby:' if no protocol is passed in through ij.protocol --- Key: DERBY-1217 URL: http://issues.apache.org/jira/browse/DERBY-1217 Project: Derby Issue Type: Improvement Components: Tools Affects Versions: 10.2.0.0, 10.1.3.0 Reporter: Andrew McIntyre Priority: Minor Attachments: derby-1217-pre.diff If no default protocol is set by passing in one with ij.protocol, ij should default to 'jdbc:derby:' . See the thread 'default ij protocol' for details: http://mail-archives.apache.org/mod_mbox/db-derby-dev/200602.mbox/[EMAIL PROTECTED] -- 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
