[jira] Assigned: (DERBY-1708) Unprivileged user can perform lock table statement on a table which he/she does not have any access rights
[ http://issues.apache.org/jira/browse/DERBY-1708?page=all ] Yip Ng reassigned DERBY-1708: - Assignee: Yip Ng Unprivileged user can perform lock table statement on a table which he/she does not have any access rights -- Key: DERBY-1708 URL: http://issues.apache.org/jira/browse/DERBY-1708 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Sun JDK 1.4.2 Reporter: Yip Ng Assigned To: Yip Ng An unprivileged user was able to lock a table for which he/she does not own. e.g.: ij version 10.2 ij connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1 (i int); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:wombat;create=true' user 'user2' as user2; WARNING 01J01: Database 'wombat' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(USER2) autocommit off; ij(USER2) lock table user1.t1 in exclusive mode; 0 rows inserted/updated/deleted sysinfo: -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: derby.jar;derbytools.jar;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: Yip Java user home: C:\Documents and Settings\Yip Java user dir: C:\work3\derby\tests\derby-10.2.1.0\lib java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\work3\derby\tests\derby-10.2.1.0\lib\derby.jar] 10.2.1.0 beta - (430903) [C:\work3\derby\tests\derby-10.2.1.0\lib\derbytools.jar] 10.2.1.0 beta - (430903 ) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.1.0 - (430903) Found support for locale: [es] version: 10.2.1.0 - (430903) Found support for locale: [fr] version: 10.2.1.0 - (430903) Found support for locale: [it] version: 10.2.1.0 - (430903) Found support for locale: [ja_JP] version: 10.2.1.0 - (430903) Found support for locale: [ko_KR] version: 10.2.1.0 - (430903) Found support for locale: [pt_BR] version: 10.2.1.0 - (430903) Found support for locale: [zh_CN] version: 10.2.1.0 - (430903) Found support for locale: [zh_TW] version: 10.2.1.0 - (430903) -- -- 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-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
[ http://issues.apache.org/jira/browse/DERBY-1651?page=comments#action_12429249 ] Satheesh Bandaram commented on DERBY-1651: -- Some general comments: 1) I think a design document to explain what each class does and how they interact with each other is required. Other option is to create a package.html file and document design/code in place. I think the second option is better. At the mininum, each class needs a detailed javadoc at the beginning and for each major method. Important and useful contribution like this may not get accepted if not documented properly. 2) Package location needs to be changed. All tools are in org.apache.derby.tools package. Best to follow existing tools like IJ, DBLOOK model so it would be easy to use and to enable derbyrun option for this tool later. 3) Looks like the code uses generics, which limit the use to JDK 1.5 platforms. While this may be ok, need to document need for JDK 1.5 platform and raise appropriate message if used in earlier platforms. Most of derby can still run on JDK 1.3 platforms, though not required for new indepedent modules. 4) There are many areas that need improvements in the code... like exception handling, importing only classes that are needed not the whole package, deleting code that is in comments etc. I understand the code is still in development. I would like to suggest you focus on completing current functionality very well, document what you have done, move code and integrate it at appropriate location and test current functionality before adding more. Better to submit partial code that is well written than submit more code that is not very usable. Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options. -- Key: DERBY-1651 URL: http://issues.apache.org/jira/browse/DERBY-1651 Project: Derby Issue Type: New Feature Components: Tools Environment: All platforms Reporter: Ramin Moazeni Assigned To: Ramin Moazeni Fix For: 10.2.1.0 Attachments: DBMigration.diff, MigrationTool-MySQLtoDerby.zip Develop a mechanism to migration databases created by other database engines to Derby. While my current interest is to migrate mySQL databases to Derby, the tool could be developed in a way to extend this mechanism to allow migration from other database engines in the future. More details of proposed functionality and implementation strategy can be found at: http://wiki.apache.org/db-derby/MysqlDerbyMigration The plan is to develop and submit patches incrementally. First patch supports migration of tables and views from mySQL database to Derby. -- 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! - TinderBox_Derby 432935 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 432935/2006-08-20 06:43:01 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1671670 2 146.92% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-432935.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/432935.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/432935.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Updated: (DERBY-1708) Unprivileged user can perform lock table statement on a table which he/she does not have any access rights
[ http://issues.apache.org/jira/browse/DERBY-1708?page=all ] Yip Ng updated DERBY-1708: -- Attachment: derby1708-10.2-stat01.txt derby1708-10.2-diff01.txt Attaching patch for DERBY-1708 for 10.2. The problem is that the lock table statement is missing the logic to collect the required privilege at compilation phase; thus, it fails to enforce the required privilege needed by the statement at execution time. Running derbyall now. The patch is ready for review. Unprivileged user can perform lock table statement on a table which he/she does not have any access rights -- Key: DERBY-1708 URL: http://issues.apache.org/jira/browse/DERBY-1708 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Sun JDK 1.4.2 Reporter: Yip Ng Assigned To: Yip Ng Attachments: derby1708-10.2-diff01.txt, derby1708-10.2-stat01.txt An unprivileged user was able to lock a table for which he/she does not own. e.g.: ij version 10.2 ij connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1 (i int); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:wombat;create=true' user 'user2' as user2; WARNING 01J01: Database 'wombat' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(USER2) autocommit off; ij(USER2) lock table user1.t1 in exclusive mode; 0 rows inserted/updated/deleted sysinfo: -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: derby.jar;derbytools.jar;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: Yip Java user home: C:\Documents and Settings\Yip Java user dir: C:\work3\derby\tests\derby-10.2.1.0\lib java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\work3\derby\tests\derby-10.2.1.0\lib\derby.jar] 10.2.1.0 beta - (430903) [C:\work3\derby\tests\derby-10.2.1.0\lib\derbytools.jar] 10.2.1.0 beta - (430903 ) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.1.0 - (430903) Found support for locale: [es] version: 10.2.1.0 - (430903) Found support for locale: [fr] version: 10.2.1.0 - (430903) Found support for locale: [it] version: 10.2.1.0 - (430903) Found support for locale: [ja_JP] version: 10.2.1.0 - (430903) Found support for locale: [ko_KR] version: 10.2.1.0 - (430903) Found support for locale: [pt_BR] version: 10.2.1.0 - (430903) Found support for locale: [zh_CN] version: 10.2.1.0 - (430903) Found support for locale: [zh_TW] version: 10.2.1.0 - (430903) -- -- 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 432847 - Sun DBTG
[Auto-generated mail] *Derby* 432847/2006-08-19 19:46:02 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.6* 3715712 0 108.94% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJDK16Jvm1.6/Limited/testSummary-432847.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJDK16Jvm1.6/432847.html *Jvm: 1.5* 1671670 2 111.87% CYGWIN_NT-5.1_i686-unknown 4671667 2 118.70% CYGWIN_NT-5.2_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 1671670 2 106.38% Linux-2.6.9-34.ELsmp_x86_64-x86_64 1671670 2 187.81% SunOS-5.10_i86pc-i386 1671670 2 139.61% SunOS-5.10_sun4u-sparc NA NA NANA SunOS-5.11_i86pc-i386 1671670 2 116.44% SunOS-5.9_sun4u-sparc Details in http://www.multinet.no/~solberg/public/Apache/Derby/Limited/testSummary-432847.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/Derby/432847.html *Jvm: 1.4* 2665663 4 109.91% CYGWIN_NT-5.1_i686-unknown NA NA NANA Linux-2.6.14-1.1644_FC4_i686-i686 1665664 4 106.65% Linux-2.6.9-34.ELsmp_x86_64-x86_64 1665664 4 222.31% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/DerbyJvm1.4/Limited/testSummary-432847.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/DerbyJvm1.4/432847.html Changes in http://www.multinet.no/~solberg/public/Apache/Derby/UpdateInfo/432847.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinarySt
[
http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12429256 ]
Knut Anders Hatlen commented on DERBY-1610:
---
Hi Tomohito,
The BatchUpdateException indicates that the error happens when executeBatch()
is invoked, not when setXXX() or addBatch() is called. I think this is OK, but
it would of course be better if the exception were raised in setXXX().
If you want to ignore these errors in parameterMapping.java, you could wrap
each call to executeBatch() like this:
try {
psi.executeBatch();
} catch (BatchUpdateException bue) {
SQLException reason = bue.getNextException();
throw (reason == null) ? bue : reason;
}
Also, do you think a release note is needed for this issue? If I understand
correctly, the client driver (and possibly JCC) will throw an exception in
situations where they didn't throw an exception before.
Updating column typed as CHAR to value passed via setBinaryStream(notNull) is
failed because of imcompatiblity of types though it was not taken as error
when setBinaryStream(null)
---
Key: DERBY-1610
URL: http://issues.apache.org/jira/browse/DERBY-1610
Project: Derby
Issue Type: Bug
Components: Network Server, Network Client
Reporter: Tomohito Nakayama
Assigned To: Tomohito Nakayama
Attachments: DERBY-1610.diff, DERBY-1610_2.diff,
parameterMapping.diff, parameterMapping.diff, TestNullChar.java
There exists difference between updating character typed column to value
passed via setBinaryStream(notNullValue) and updating the column to value
passed via setBinaryStream(null).
This difference is problematic because it does not exist in Embedded mode.
--
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-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429259 ] Mayuresh Nirhali commented on DERBY-418: I tried modifying the finalize method of embedResultSet to close singleuseActivation and that seems to have worked for good reasons. So, when GC operations clean up resultset objects the associated activation objects will be closed, thus freeing up some more memory. But, for the reproducible case, this is not the complete solution. This change differs the leak for a long period but does not completely fix it. I tried the same fix for the repro in DERBY-1142 (without resultset.close statement) and did not see any leak there. I think, this can be a good fix for now until the extreme case is tracked down. I will run derbyall with this fix and produce a patch soon. outofmemory error when running large query in autocommit=false mode --- Key: DERBY-418 URL: http://issues.apache.org/jira/browse/DERBY-418 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.1.0 Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. Reporter: Sunitha Kambhampati Assigned To: Mayuresh Nirhali Fix For: 10.2.1.0 Attachments: AutoCommitTest.java On the derby-user list, Chris reported tihs problem with his application and also a repro for the problem. I am logging the jira issue so it doesnt get lost in all the mail. (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) --from chris's post-- I'm running a set of ~5 queries on one table, using inserts and updates, and i want to be able to roll them back so i turned off autocommit using setAutoCommit(false). As the update runs, the memory used by the JVM increases continually until i get the following exception about 20% of the way through: ERROR 40XT0: An internal error was identified by RawStore module. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) at vi.hotspot.database.DataInterface._query(DataInterface.java:181) at vi.hotspot.database.DataInterface.query(DataInterface.java:160) at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) vi.hotspot.exception.ServerTransactionException at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) at
[jira] Commented: (DERBY-1142) Metadata calls leak memory
[
http://issues.apache.org/jira/browse/DERBY-1142?page=comments#action_12429260 ]
Mayuresh Nirhali commented on DERBY-1142:
-
If the singleUseActivation is closed in the finalize method of EmdebResultSet
then the memory leak is not observed even in this extreme case. While, this may
not be a complete fix, but certainly one of fixes.
Please see DERBY-418 for more details.
Metadata calls leak memory
--
Key: DERBY-1142
URL: http://issues.apache.org/jira/browse/DERBY-1142
Project: Derby
Issue Type: Bug
Components: JDBC
Affects Versions: 10.1.2.1, 10.2.1.0
Reporter: Knut Anders Hatlen
Priority: Minor
Attachments: 1142_close_single_use_activations_draft.txt,
metadataloop.java
When calling a DatabaseMetaData method that returns a ResultSet,
memory is leaked. A loop like this (using the embedded driver)
while (true) {
ResultSet rs = dmd.getSchemas();
rs.close();
}
will eventually cause an OutOfMemoryError.
--
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-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinarySt
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12429263 ] Tomohito Nakayama commented on DERBY-1610: -- The mystery was the reason why test of setNull generats different error message than not null method in the test. I found that method checkForInvalidConversion(SQLException sqle) was used in the test of setXXX and handles BatchUpdateException. This method was not used in the test of setNull, then BatchUpdateException was simply dumped. I think we should use the checkForInvalidConversion(SQLException sqle) method in the case of setNull also. Then, this exception can be handled correctly in the test program. Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- 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-418) outofmemory error when running large query in autocommit=false mode
[ http://issues.apache.org/jira/browse/DERBY-418?page=comments#action_12429264 ] Daniel John Debrunner commented on DERBY-418: - Closing the activation directly in the finalize method will lead to problems. The close of the activation requires obtaining synchronization which is not recommended for the finalizer thread, it can lead to deadlocks with the thread that owns the connection and its synchronization. That's why the activations are closed indirectly through the set inactive state mechanism. outofmemory error when running large query in autocommit=false mode --- Key: DERBY-418 URL: http://issues.apache.org/jira/browse/DERBY-418 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.1.1.0 Environment: I can reproduce this problem on Win2k/ T42 laptop. jdk141. Reporter: Sunitha Kambhampati Assigned To: Mayuresh Nirhali Fix For: 10.2.1.0 Attachments: AutoCommitTest.java On the derby-user list, Chris reported tihs problem with his application and also a repro for the problem. I am logging the jira issue so it doesnt get lost in all the mail. (http://www.mail-archive.com/derby-user@db.apache.org/msg01258.html) --from chris's post-- I'm running a set of ~5 queries on one table, using inserts and updates, and i want to be able to roll them back so i turned off autocommit using setAutoCommit(false). As the update runs, the memory used by the JVM increases continually until i get the following exception about 20% of the way through: ERROR 40XT0: An internal error was identified by RawStore module. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java) at org.apache.derby.impl.store.raw.xact.Xact.setActiveState(Xact.java) at org.apache.derby.impl.store.raw.xact.Xact.openContainer(Xact.java) at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.init(OpenConglomerate.java) at org.apache.derby.impl.store.access.heap.Heap.open(Heap.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.QueryTreeNode.getSchemaDescriptor(QueryTreeNode.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindTableDescriptor(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromBaseTable.bindNonVTITables(FromBaseTable.java) at org.apache.derby.impl.sql.compile.FromList.bindTables(FromList.java) at org.apache.derby.impl.sql.compile.SelectNode.bindNonVTITables(SelectNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bindTables(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.DMLStatementNode.bind(DMLStatementNode.java) at org.apache.derby.impl.sql.compile.ReadCursorNode.bind(ReadCursorNode.java) at org.apache.derby.impl.sql.compile.CursorNode.bind(CursorNode.java) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java) at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java) at org.apache.derby.impl.jdbc.EmbedStatement.executeQuery(EmbedStatement.java) at vi.hotspot.database.DataInterface._query(DataInterface.java:181) at vi.hotspot.database.DataInterface.query(DataInterface.java:160) at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:518) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) vi.hotspot.exception.ServerTransactionException at vi.hotspot.database.UpdateManager.updatePartialTable(UpdateManager.java:555) at vi.hotspot.database.UpdateManager.updatePartialTables(UpdateManager.java:619) at vi.hotspot.database.UpdateManager.run(UpdateManager.java:924) at java.lang.Thread.run(Thread.java:534) Derby is running in standalone mode. -- This message is automatically generated by JIRA. - If you think it
[jira] Commented: (DERBY-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinarySt
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12429265 ] Tomohito Nakayama commented on DERBY-1610: -- I think release note should be prepared for this issue, including difference originally introduced in DERBY-1535. Is it sufficient to write at http://wiki.apache.org/db-derby/TenTwoRelease? Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- 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] Subscription: Derby: JIRA issues with patch available
Issue Subscription Filter: Derby: JIRA issues with patch available (21 issues) Subscriber: derby-dev Key Summary DERBY-1651 Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options. http://issues.apache.org/jira/browse/DERBY-1651 DERBY-1500 PreparedStatement#setObject(int parameterIndex, Object x) throws SQL Exception when binding Short value in embedded mode http://issues.apache.org/jira/browse/DERBY-1500 DERBY-883 Enhance GROUP BY clause to support expressions instead of just column references. http://issues.apache.org/jira/browse/DERBY-883 DERBY-1636 document encryption of an un-encrypted database and re-encryption with new password/key. http://issues.apache.org/jira/browse/DERBY-1636 DERBY-1582 REVOKE statement does not generate a warning when no privileges are revoked. http://issues.apache.org/jira/browse/DERBY-1582 DERBY-801 Allow parallel access to data files. http://issues.apache.org/jira/browse/DERBY-801 DERBY-1559 when receiving a single EXTDTA object representing a BLOB, the server do not need to read it into memory before inserting it into the DB http://issues.apache.org/jira/browse/DERBY-1559 DERBY-1292 ClassCastException in ClientDriver when using CLOB columns and batch updates http://issues.apache.org/jira/browse/DERBY-1292 DERBY-1405 New javadoc needs to be wired into documentation http://issues.apache.org/jira/browse/DERBY-1405 DERBY-1130 Client should not allow databaseName to be set with setConnectionAttributes http://issues.apache.org/jira/browse/DERBY-1130 DERBY-1655 Document XML functionality for 10.2 http://issues.apache.org/jira/browse/DERBY-1655 DERBY-119 Add ALTER TABLE option to change column from NULL to NOT NULL http://issues.apache.org/jira/browse/DERBY-119 DERBY-1621 Trigger action statement is not recompile when there is a change that would affect it. http://issues.apache.org/jira/browse/DERBY-1621 DERBY-1473 Add cut-off and truncation logic to streaming classes in the embedded driver http://issues.apache.org/jira/browse/DERBY-1473 DERBY-889 with client getTimestamp on a TIME column will print the date 1900-01-01 instead of the current date http://issues.apache.org/jira/browse/DERBY-889 DERBY-1659 Document describe and show tables functionality http://issues.apache.org/jira/browse/DERBY-1659 DERBY-1417 Add new, lengthless overloads to the streaming api http://issues.apache.org/jira/browse/DERBY-1417 DERBY-1643 A revoke execute ... restrict should fail if there are dependent objects on the execute privilege http://issues.apache.org/jira/browse/DERBY-1643 DERBY-815 Prevent unneeded object creation and excessive decoding in parseSQLDTA_work() http://issues.apache.org/jira/browse/DERBY-815 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646 DERBY-1194 Derby Server and Administration Guide - Managing the Derby Network Server http://issues.apache.org/jira/browse/DERBY-1194
[jira] Updated: (DERBY-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStre
[ http://issues.apache.org/jira/browse/DERBY-1610?page=all ] Knut Anders Hatlen updated DERBY-1610: -- Derby Info: [Release Note Needed] Adding the Release Note Needed flag to keep it on the release manager's radar. Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- 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-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinary
Oh. I see ... Knut Anders Hatlen (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-1610?page=all ] Knut Anders Hatlen updated DERBY-1610: -- Derby Info: [Release Note Needed] Adding the Release Note Needed flag to keep it on the release manager's radar. Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- /* Tomohito Nakayama [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Naka http://www5.ocn.ne.jp/~tomohito/TopPage.html */
[jira] Updated: (DERBY-1708) Unprivileged user can perform lock table statement on a table which he/she does not have any access rights
[ http://issues.apache.org/jira/browse/DERBY-1708?page=all ] Yip Ng updated DERBY-1708: -- Derby Info: [Patch Available] Unprivileged user can perform lock table statement on a table which he/she does not have any access rights -- Key: DERBY-1708 URL: http://issues.apache.org/jira/browse/DERBY-1708 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Environment: Sun JDK 1.4.2 Reporter: Yip Ng Assigned To: Yip Ng Attachments: derby1708-10.2-diff01.txt, derby1708-10.2-stat01.txt An unprivileged user was able to lock a table for which he/she does not own. e.g.: ij version 10.2 ij connect 'jdbc:derby:wombat;create=true' user 'user1' as user1; WARNING 01J14: SQL authorization is being used without first enabling authentication. ij create table t1 (i int); 0 rows inserted/updated/deleted ij connect 'jdbc:derby:wombat;create=true' user 'user2' as user2; WARNING 01J01: Database 'wombat' not created, connection made to existing database instead. WARNING 01J14: SQL authorization is being used without first enabling authentication. ij(USER2) autocommit off; ij(USER2) lock table user1.t1 in exclusive mode; 0 rows inserted/updated/deleted sysinfo: -- Java Information -- Java Version:1.4.2_12 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files\Java\j2re1.4.2_12 Java classpath: derby.jar;derbytools.jar;. OS name: Windows XP OS architecture: x86 OS version: 5.1 Java user name: Yip Java user home: C:\Documents and Settings\Yip Java user dir: C:\work3\derby\tests\derby-10.2.1.0\lib java.specification.name: Java Platform API Specification java.specification.version: 1.4 - Derby Information JRE - JDBC: J2SE 1.4.2 - JDBC 3.0 [C:\work3\derby\tests\derby-10.2.1.0\lib\derby.jar] 10.2.1.0 beta - (430903) [C:\work3\derby\tests\derby-10.2.1.0\lib\derbytools.jar] 10.2.1.0 beta - (430903 ) -- - Locale Information - Current Locale : [English/United States [en_US]] Found support for locale: [de_DE] version: 10.2.1.0 - (430903) Found support for locale: [es] version: 10.2.1.0 - (430903) Found support for locale: [fr] version: 10.2.1.0 - (430903) Found support for locale: [it] version: 10.2.1.0 - (430903) Found support for locale: [ja_JP] version: 10.2.1.0 - (430903) Found support for locale: [ko_KR] version: 10.2.1.0 - (430903) Found support for locale: [pt_BR] version: 10.2.1.0 - (430903) Found support for locale: [zh_CN] version: 10.2.1.0 - (430903) Found support for locale: [zh_TW] version: 10.2.1.0 - (430903) -- -- 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-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinarySt
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12429278 ] Knut Anders Hatlen commented on DERBY-1610: --- With the DERBY-1610_2.diff patch, setBinaryStream(null), setBlob(null) and setNull(Types.BLOB) throw exception if they are called on a parameter of type CHAR, VARCHAR, LONGVARCHAR or CLOB. However, they can still be used to set parameters of other types (for instance SHORT, INTEGER, FLOAT, DOUBLE and TIMESTAMP) to null. I think it would be better and more consistent behaviour if all of these failed as well. In fact, all other setXXX methods can be used to set null values on parameters of all types. I find it a bit unintuitive that only the combinations mentioned above should raise exceptions. Is it possible to make the calcJdbcTypeForNullValue() more complete so that all setXXX(null) calls on parameters of incompatible type throw an exception? Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- 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-1582) REVOKE statement does not generate a warning when no privileges are revoked.
[ http://issues.apache.org/jira/browse/DERBY-1582?page=all ] Deepa Remesh updated DERBY-1582: Derby Info: (was: [Patch Available]) With v2 patch, derbyall ran with no new failures. But the test additions conflict with changes in DERBY-1538. Unchecking patch available flag till check and upload new patch. REVOKE statement does not generate a warning when no privileges are revoked. Key: DERBY-1582 URL: http://issues.apache.org/jira/browse/DERBY-1582 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0 Reporter: Daniel John Debrunner Assigned To: Deepa Remesh Attachments: d1582_v1.diff, d1582_v1.status, d1582_v2.diff, d1582_v2.status SQL 2003 standard, section 12.7 revoke statement, item 17 under general rules indicates the statement completes with the condition 'warning ? privilege not revoked.' when no matching privilege is revoked. -- 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! - TinderBox_Derby 432972 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 432972/2006-08-20 16:52:25 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 1671670 2 147.65% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-432972.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/432972.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/432972.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
[jira] Commented: (DERBY-1610) Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinarySt
[ http://issues.apache.org/jira/browse/DERBY-1610?page=comments#action_12429286 ] Tomohito Nakayama commented on DERBY-1610: -- Technically, I think we can make the calcJdbcTypeForNullValue() *more complete*. However, I'm not sure we should do it right now. At first, DERBY-1610 started from side effects of DERBY-1535, improvement of streaming from client to server. It was found this side effect of DERBY-1535 has meaning of partial fix for DERBY-310. Then, DERBY-1610 started. //Modification of DERBY-1535 will be overwrtten almostly by DERBY-1559. //However DERBY-1559 has the same side effect as DERBY-1535, because the code of DERBY-1559 passes InputStream object instead of byte array to the Engine as the code of DERBY-1535 does. Historically this issue had meaning of accepting side effect of DERBY-1535 (and DERBY-1559) as partial fix for DERBY-310, at least in my true mind. However, if it comes to *complete* fix for DERBY-310 around type compatibility, I concern that throwing many new exceptions may cause large impact to the user, even if it was the behavior in Embedded mode. If we aim *complete* fix for DERBY-310 around type compatibility, I think some more carefulness is needed, because sphere to be influenced is pretty large if we aim *completion* ... Well. I think we need to know what is the carefulness needed in this issue Release note .? may be ... Updating column typed as CHAR to value passed via setBinaryStream(notNull) is failed because of imcompatiblity of types though it was not taken as error when setBinaryStream(null) --- Key: DERBY-1610 URL: http://issues.apache.org/jira/browse/DERBY-1610 Project: Derby Issue Type: Bug Components: Network Server, Network Client Reporter: Tomohito Nakayama Assigned To: Tomohito Nakayama Attachments: DERBY-1610.diff, DERBY-1610_2.diff, parameterMapping.diff, parameterMapping.diff, TestNullChar.java There exists difference between updating character typed column to value passed via setBinaryStream(notNullValue) and updating the column to value passed via setBinaryStream(null). This difference is problematic because it does not exist in Embedded mode. -- 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-1734) Simplify building of SystemColumn array in CatalogRowFactory implementations.
Simplify building of SystemColumn array in CatalogRowFactory implementations.
--
Key: DERBY-1734
URL: http://issues.apache.org/jira/browse/DERBY-1734
Project: Derby
Issue Type: Sub-task
Reporter: Daniel John Debrunner
Assigned To: Daniel John Debrunner
Priority: Minor
The implementations of CatalogRowFactory.buildColumnList() can be simplified in
a number of ways:
1) precision scale are always passed in as zero and can be removed
2) adding static factory methods to SystemColumnImpl would ease the building
of the arrays by not requiring the additional redundant arguments the
constructor call forces today, e.g. max length i snot required to create an
INTEGER column.
3) The column's position is not required to be stored in the SytstemColumn
class, it's defined by the position in the array
4) arrays can be built using
new SystemColumn[] { ... }
syntax instead of the existing
columnList[0] = ...
columnList[1] = ...
or
columnList[index++] = ...
columnList[index++] = ...
--
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
Cache Manager: Summer Progress
Hi all, I'm a student working on improving the CacheManager in Derby as part of Google's Summer of Code. Over the summer, I have looked at two ways of improving it. In my first approach, I implemented the ClockPro algorithm. In my second approach, I tried to separate the cache implementation from the replacement policy using the PluggableCache architecture. This allows for many policies to be plugged in. I wrote a small report summarizing my summer work including some early results. I'm planning to port some benchmarks and evaluate the design further. I'll let you know of my progress. I appreciate everyone's help over the summer and would like your comments on my report and my design choices. I have placed the code and report on my website at: Report http://www.eecg.toronto.edu/~gokul/derby/derby-report-aug-19-2006.pdf Code http://www.eecg.toronto.edu/~gokul/derby/code/aug-19-2006/ Thanks, Gokul
[jira] Commented: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen
[ http://issues.apache.org/jira/browse/DERBY-766?page=comments#action_12429307 ] Daniel John Debrunner commented on DERBY-766: - Issue now fixed, with sufficient memory seen over 6000 unions supported in largeCodeGen test. DERBY-1315 stops this being tested in the largeCodeGen test. As committed that test only checks 1000 unions. DERBY-1315 should address increasing that when the memory usage is fixed. Improve code generation to handle 5000 unions in a select the union test in largeCodeGen -- Key: DERBY-766 URL: http://issues.apache.org/jira/browse/DERBY-766 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.2.1.0 Reporter: Kathey Marsden Assigned To: Daniel John Debrunner Fix For: 10.2.1.0 A good incremental improvement for code generation for 10.2 would be to handle 5000 unions in the largeCodeGen test. eg. largeUnionSelect(con, viewName, 5000); should pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-766) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen
[ http://issues.apache.org/jira/browse/DERBY-766?page=all ] Daniel John Debrunner resolved DERBY-766. - Fix Version/s: 10.3.0.0 Resolution: Fixed Changes merged to the 10.2 branch (current version is 10.2.1.0) Improve code generation to handle 5000 unions in a select the union test in largeCodeGen -- Key: DERBY-766 URL: http://issues.apache.org/jira/browse/DERBY-766 Project: Derby Issue Type: Sub-task Components: Services Affects Versions: 10.2.1.0 Reporter: Kathey Marsden Assigned To: Daniel John Debrunner Fix For: 10.2.1.0, 10.3.0.0 A good incremental improvement for code generation for 10.2 would be to handle 5000 unions in the largeCodeGen test. eg. largeUnionSelect(con, viewName, 5000); should pass. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-216) expand largeCodeGen.java test
[ http://issues.apache.org/jira/browse/DERBY-216?page=comments#action_12429314 ] Daniel John Debrunner commented on DERBY-216: - The insert case is included in largeCodeGen now. expand largeCodeGen.java test - Key: DERBY-216 URL: http://issues.apache.org/jira/browse/DERBY-216 Project: Derby Issue Type: Sub-task Components: Test Affects Versions: 10.1.2.1 Reporter: Kathey Marsden the largeCodeGen test needs to be expanded to include other cases that genreate large amounts of byte code. For example: large in clause large insert statement that inserts many rows sql statements with large constant values It is best if the verious tests just use a variable that can be bumped higher and higher for testing and if individual cases are isolated. Possible approaches, think of ways to make sql statements really big that will take different code paths. Look in the code for instances of statementNumHitLimit and create cases that pass through that code. Those cases may pass but the hope is to get rid of these calls in favor of splitting the code in a centralized way, so add the tests to largeCodeGen even if they don't fail. -- 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] Resolved: (DERBY-176) Derby throws ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.aced07c066x0102xca87x3319x00004aa5686e1 during execution of large q
[ http://issues.apache.org/jira/browse/DERBY-176?page=all ] Daniel John Debrunner resolved DERBY-176. - Fix Version/s: 10.2.1.0 10.3.0.0 Resolution: Fixed Changes for DERBY-766 and under this bug ensured that a Query too complex exception is thrown if the resulting generated class will not be loadable by the JVM due to exceeding limits. Derby throws ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.aced07c066x0102xca87x3319x4aa5686e1 during execution of large query --- Key: DERBY-176 URL: http://issues.apache.org/jira/browse/DERBY-176 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.0.2.2, 10.0.2.1, 10.0.2.0, 10.1.1.0 Reporter: Kathey Marsden Assigned To: Daniel John Debrunner Fix For: 10.2.1.0, 10.3.0.0 Attachments: largeCodeGen.java When executing a large query or oather large operations, Derby throws a java linkage exception. This is because the generated byte code exceeds the JVM limits for method sizes constant pool entries etc, the amount of code in a conditional etc. The attached repro demonstrates the problem but the problem can also occur for other operations that generate lots of byte code. The repro is just a new functional test, so should be copied to derbyTesting/functionTests/lang/largeCodeGen.java and run like java -Djvmflags=-Xmx512M org.apache.derbyTesting.harness.RunTest lang/largeCodeGen When this problem is fixed additional scenarios should be added to this test. ERROR XBCM1: Java linkage error thrown during load of generated class org.apache.derby.exe.aced07c066x0102xca87x3319x4aa5686e1. at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:315) at org.apache.derby.impl.services.reflect.DatabaseClasses.loadGeneratedClass(DatabaseClasses.java:162) at org.apache.derby.impl.services.bytecode.GClass.getGeneratedClass(GClass.java:59) at org.apache.derby.impl.sql.compile.ExpressionClassBuilder.getGeneratedClass(ExpressionClassBuilder.java:920) at org.apache.derby.impl.sql.compile.StatementNode.generate(StatementNode.java:270) at org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:432) at org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:107) at org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:688) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.init(EmbedPreparedStatement.java:118) at org.apache.derby.impl.jdbc.EmbedPreparedStatement20.init(EmbedPreparedStatement20.java:82) at org.apache.derby.impl.jdbc.EmbedPreparedStatement30.init(EmbedPreparedStatement30.java:62) at org.apache.derby.jdbc.Driver30.newEmbedPreparedStatement(Driver30.java:92) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:675) at org.apache.derby.impl.jdbc.EmbedConnection.prepareStatement(EmbedConnection.java:519) at org.apache.derbyTesting.functionTests.tests.lang.largeCodeGen.main(largeCodeGen.java:86) Exception in thread main -- 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-1735) Large number of rows in a VALUES clause (e.g. for an INSERT) can result in a StackOverflowError
Large number of rows in a VALUES clause (e.g. for an INSERT) can result in a StackOverflowError --- Key: DERBY-1735 URL: http://issues.apache.org/jira/browse/DERBY-1735 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.2.1.0, 10.3.0.0 Reporter: Daniel John Debrunner Priority: Minor With DERBY-766 / DERBY-1714extending the limit for number of rows in a VALUES clause the next error seen is a stack overflow. issue can be seen by increasing the number of rows in the testInsertValues portion of largeCodeGen -- 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-1315) Statement optimization/compilation fails with OutOfMemoryException in largeCodeGen test with embedded and framework DerbyNetClient
[ http://issues.apache.org/jira/browse/DERBY-1315?page=comments#action_12429317 ] Daniel John Debrunner commented on DERBY-1315: -- To see this problem with largeCodeGen one must increase the number of union clauses created in the testUnions method of largeCodeGen (now a JUnit test run as part of derbyall) Statement optimization/compilation fails with OutOfMemoryException in largeCodeGen test with embedded and framework DerbyNetClient --- Key: DERBY-1315 URL: http://issues.apache.org/jira/browse/DERBY-1315 Project: Derby Issue Type: Bug Components: SQL, Regression Test Failure Affects Versions: 10.2.1.0 Environment: Linux - Suse 2.6.5-7.252 Reporter: Ramandeep Kaur Fix For: 10.2.1.0 Attachments: 1315-comparison.html, largeCodeGen.java, largeCodeGen.out, largeCodeGen.sql, largeCodeGen.tmp, largeCodeGen.tmpmstr The test case lang/largeCodeGen.java was run as is without giving any -Djvmflags=-mx512M -ms512M and gave the following error: *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:30:04 *** 27a28 JVMST109: Insufficient space in Javaheap to satisfy allocation request Test Failed. *** End: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:32:01 *** Then the test case lang/largeCodeGen.java was run with -Djvmflags=-mx512M -ms512M, and it gave the following error: PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a19 FAILED QUERY: IN clause with 97000 parameters. Test Failed. Then I modified test case lang/largeCodeGen.java to set PRINT_FAILURE_EXCEPTION to true and ran the test again. This time I got the following error and stack trace: MasterFileName = master/largeCodeGen.out 15a16,18 java.sql.SQLException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_leng th (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203ax d010x50a9065e9. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_length (65577 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e9 . ... 4 more 19 del PASS: IN clause with 97000 parameters 20 del PASS: PREPARE: IN clause with 98000 parameters 21 del PASS: IN clause with 98000 parameters 22 del FAILED QUERY: IN clause with 99000 parameters. 22a22,29 FAILED QUERY: IN clause with 97000 parameters. java.sql.SQLException: The parameter position '31,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.setInt(PreparedStatement .java(Compiled Code)) Caused by: org.apache.derby.client.am.SqlException: The parameter position '31 ,465' is out of range. The number of parameters for this prepared statement is '31,464'. at org.apache.derby.client.am.PreparedStatement.checkForValidParameterIn dex(PreparedStatement.java(Compiled Code)) at org.apache.derby.client.am.PreparedStatement.checkSetterPreconditions (PreparedStatement.java(Inlined Compiled Code)) at org.apache.derby.client.am.PreparedStatement.setIntX(PreparedStatemen t.java(Inlined Compiled Code)) ... 5 more 27a35,37 java.sql.SQLException : Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expressions or breaking up the query and storing interim results in a temporary table can often help resolve this error . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSe t code_length (69127 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203axd010x50a9065e11. Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try rewriting the query to remove complexity. Eliminating many duplicate expression s or breaking up the query and storing interim results in a temporary table can often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s) exceeded:
Regression Test Failure! - TinderBox_Derby 433085 - Sun DBTG
[Auto-generated mail] *TinderBox_Derby* 433085/2006-08-21 01:22:24 CEST *derbyall* Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* 2672670 2 154.08% SunOS-5.10_i86pc-i386 Details in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/testSummary-433085.html Attempted failure analysis in http://www.multinet.no/~solberg/public/Apache/Failures/TinderBox_Derby/433085.html Changes in http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/UpdateInfo/433085.txt ( All results in http://www.multinet.no/~solberg/public/Apache/index.html )
Re: [jira] Commented: (DERBY-1651) Develop a mechanism to migrate mySQL databases to Derby. Migration tool should include both schema and data migration options.
On 8/20/06, Satheesh Bandaram (JIRA) derby-dev@db.apache.org wrote: 3) Looks like the code uses generics, which limit the use to JDK 1.5 platforms. While this may be ok, need to document need for JDK 1.5 platform and raise appropriate message if used in earlier platforms. Most of derby can still run on JDK 1.3 platforms, though not required for new indepedent modules. As well as being documented, the tool should print a useful error and then exit if a user attempts to run it on an unsupported JVM. andrew
