[jira] Resolved: (DERBY-2050) Manipulating CachedItems could be more efficient
[ http://issues.apache.org/jira/browse/DERBY-2050?page=all ] Knut Anders Hatlen resolved DERBY-2050. --- Resolution: Fixed Assignee: Dyre Tjeldvoll Thanks Dyre. Derbyall and the JUnit tests ran cleanly (except a couple of known issues). Committed revision 472803. > Manipulating CachedItems could be more efficient > > > Key: DERBY-2050 > URL: http://issues.apache.org/jira/browse/DERBY-2050 > Project: Derby > Issue Type: Improvement > Components: Performance >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll > Assigned To: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2050.diff, derby-2050.stat, derby-2050.v2.diff > > > CachedItem's state is currently recorded in bit fields of an integer > variable. Changing this to 6 boolean member variables reduces cpu usage. -- 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-2047) TestDataSourceFactory doesn't work correctly outside the old harness
[ http://issues.apache.org/jira/browse/DERBY-2047?page=comments#action_12448383 ] Knut Anders Hatlen commented on DERBY-2047: --- It seems like the 472187 and/or 472228 commit broke a couple of tests in the old harness: * Diff file derbyall/derbynetclientmats/DerbyNetClient/derbynetmats/derbynetmats/ShutDownDBWhenNSShutsDownTest.diff *** Start: ShutDownDBWhenNSShutsDownTest jdk1.6.0-rc DerbyNetClient derbynetmats:derbynetmats 2006-11-09 04:35:03 *** 0 add > .F. > There was 1 failure: > 1) > testEngineShutdownDoesNotTakeDownNS(org.apache.derbyTesting.functionTests.tests.derbynet.ShutDownDBWhenNSShutsDownTest)junit.framework.ComparisonFailure: > Engine shutdown expected: but was: > FAILURES!!! > Tests run: 2, Failures: 1, Errors: 0 Test Failed. *** End: ShutDownDBWhenNSShutsDownTest jdk1.6.0-rc DerbyNetClient derbynetmats:derbynetmats 2006-11-09 04:35:15 *** * Diff file derbyall/jdbc40/VerifySignatures.diff *** Start: VerifySignatures jdk1.6.0-rc derbyall:jdbc40 2006-11-09 04:24:15 *** 0 add > Failed to invoke suite():java.sql.SQLException: Database 'wombat' not found. Test Failed. *** End: VerifySignatures jdk1.6.0-rc derbyall:jdbc40 2006-11-09 04:24:16 *** > TestDataSourceFactory doesn't work correctly outside the old harness > > > Key: DERBY-2047 > URL: http://issues.apache.org/jira/browse/DERBY-2047 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Knut Anders Hatlen > Assigned To: Daniel John Debrunner > Attachments: DataSource.java, derby-2047.diff, derby-2047.stat > > > TestDataSourceFactory uses TestUtil to create DataSource, > ConnectionPoolDataSource and XADataSource objects. TestUtil needs to run in > the old harness in order to detect which framework it is running under, so it > will create embedded data sources for all JUnit tests that are run outside > the old harness. -- 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 Report - tinderbox_trunk15 472742 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk15* 472742/2006-11-09 03:42:34 CET Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* SunOS-5.10_i86pc-i386 3519516 2 121.17% derbyall 020322032 0 109.83% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/Limited/testSummary-472742.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/FailReports/472742.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/UpdateInfo/472742.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Regression Test Report - tinderbox_trunk15 472704 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk15* 472704/2006-11-09 00:52:18 CET Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* SunOS-5.10_i86pc-i386 3519516 2 121.21% derbyall 020322032 0 110.52% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/Limited/testSummary-472704.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/FailReports/472704.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/UpdateInfo/472704.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[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_12448348 ] Rajesh Kartha commented on DERBY-396: - I tend to agree with Bryan. As I understand ,the only issue that remains is to ALTER a COLUMN's DATATYPE, and the work-around provided in DERBY-1515 seems reasonable enough. -Rajesh > 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_12448331 ] Bryan Pendleton commented on DERBY-396: --- I propose to mark this issue resolved for 10.3. Can anybody see any part of this feature which has not yet been addressed? Kathey, I know you were concerned that we not prematurely close this issue. How do you feel about marking it as resolved at this point? > 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-2063) derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform
[ http://issues.apache.org/jira/browse/DERBY-2063?page=comments#action_12448330 ] Suresh Thalamati commented on DERBY-2063: - This test failure is not specific to Linux , it fails on other platforms(windows , SunOS) tooo . http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/testlog/SunOS-5.10_i86pc-i386/472613-derbyall_diff.txt > derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on > Linux platform > > > Key: DERBY-2063 > URL: http://issues.apache.org/jira/browse/DERBY-2063 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.2.1.8 >Reporter: Manjula Kutty > > *** Start: ShutDownDBWhenNSShutsDownTest jdk1.5.0 DerbyNetClient > derbynetmats:derbynetmats 2006-11-07 23:29:20 *** > 0 add > > .F. > > There was 1 failure: > > 1) > > testEngineShutdownDoesNotTakeDownNS(org.apache.derbyTesting.functionTests.tests.derbynet.ShutDownDBWhenNSShutsDownTest)junit.framework.ComparisonFailure: > > Engine shutdown expected: but was:<08001> > > FAILURES!!! > > Tests run: 2, Failures: 1, Errors: 0 > Test Failed. -- 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-1515) Provide ALTER TABLE functionality to change a column's data type
[ http://issues.apache.org/jira/browse/DERBY-1515?page=all ] Bryan Pendleton resolved DERBY-1515. Resolution: Won't Fix I think that the proposed workaround (adding a new column, populating it, dropping the old column, and then renaming the new column to the desired name) is adequate for now. > 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.1.0, 10.2.1.6, 10.1.2.1, 10.1.3.1 >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] Updated: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Affects Version/s: 10.2.1.6
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: Documentation, SQL
>Affects Versions: 10.2.1.6, 10.3.0.0
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: derby-1770-tests-v2.diff, derby-1770-tests-v2.stat,
> derby-1770-tests.diff, derby-1770-tests.stat, derby1953-trunk-diff01.txt,
> derby1953-trunk-diff02.txt, derby1953-trunk-diff03.txt,
> derby1953-trunk-diff04.txt, derby1953-trunk-stat01.txt,
> derby1953-trunk-stat02.txt, derby1953-trunk-stat03.txt,
> derby1953-trunk-stat04.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | 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] Updated: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Affects Version/s: 10.3.0.0
(was: 10.2.1.6)
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: Documentation, SQL
>Affects Versions: 10.3.0.0
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: derby-1770-tests-v2.diff, derby-1770-tests-v2.stat,
> derby-1770-tests.diff, derby-1770-tests.stat, derby1953-trunk-diff01.txt,
> derby1953-trunk-diff02.txt, derby1953-trunk-diff03.txt,
> derby1953-trunk-diff04.txt, derby1953-trunk-stat01.txt,
> derby1953-trunk-stat02.txt, derby1953-trunk-stat03.txt,
> derby1953-trunk-stat04.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | 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] Updated: (DERBY-1953) Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
[ http://issues.apache.org/jira/browse/DERBY-1953?page=all ]
Yip Ng updated DERBY-1953:
--
Fix Version/s: 10.3.0.0
> Make FOR EACH clause and MODE DB2SQL in CREATE TRIGGER statement optional
> -
>
> Key: DERBY-1953
> URL: http://issues.apache.org/jira/browse/DERBY-1953
> Project: Derby
> Issue Type: Improvement
> Components: Documentation, SQL
>Affects Versions: 10.3.0.0
> Environment: Any
>Reporter: Yip Ng
> Assigned To: Yip Ng
>Priority: Minor
> Fix For: 10.3.0.0
>
> Attachments: derby-1770-tests-v2.diff, derby-1770-tests-v2.stat,
> derby-1770-tests.diff, derby-1770-tests.stat, derby1953-trunk-diff01.txt,
> derby1953-trunk-diff02.txt, derby1953-trunk-diff03.txt,
> derby1953-trunk-diff04.txt, derby1953-trunk-stat01.txt,
> derby1953-trunk-stat02.txt, derby1953-trunk-stat03.txt,
> derby1953-trunk-stat04.txt
>
>
> According to SQL:2003 standard, section 11.39 , under
> Syntax Rules item 8:
> If neither FOR EACH ROW nor FOR EACH STATEMENT is specified, then FOR EACH
> STATEMENT is implicit.
> [ FOR EACH { ROW | 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] Updated: (DERBY-2042) Provide documentation for new RENAME COLUMN statement
[ http://issues.apache.org/jira/browse/DERBY-2042?page=all ] Bryan Pendleton updated DERBY-2042: --- Attachment: renameColumnDoc_v3_changedSyntaxRefs.diff rrefsqljrenamecolumnstatement.html Attached is renameColumnDoc_v3_changedSyntaxRefs.diff, an updated patch proposal which incorporates Knut Anders's suggestions: 1) The text describing the examples uses italics to refer to the table and column names in the examples, rather than putting them in quotation marks, which I agree looks superior. 2) The syntax block now refers to the table-name and simple-column-name topics, which don't appear to be a perfect match, but are pretty close to it. As Knut Anders observes, this should help to describe the various combinations of schema name, table name, and column name more rigorously. Please have a look. I've attached the HTML output file as well, for easier review. > Provide documentation for new RENAME COLUMN statement > - > > Key: DERBY-2042 > URL: http://issues.apache.org/jira/browse/DERBY-2042 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton >Priority: Minor > Attachments: renameColumnDoc_v1.diff, renameColumnDoc_v2.diff, > renameColumnDoc_v3_changedSyntaxRefs.diff, > rrefsqljrenamecolumnstatement.html, rrefsqljrenamecolumnstatement.html, > rrefsqljrenamecolumnstatement.html > > > DERBY-1490 proposes to add a new RENAME COLUMN statement. Assuming that such > a statement is added, we need to update the documentation to describe this > new statement. DERBY-1490 describes the behavior of the statement in detail; > this issue is just to track the documentation, which I intend to address > separately after the DERBY-1490 changes are committed. -- 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-1490) Provide ALTER TABLE RENAME COLUMN functionality
[ http://issues.apache.org/jira/browse/DERBY-1490?page=all ] Bryan Pendleton resolved DERBY-1490. Fix Version/s: 10.3.0.0 Resolution: Fixed Derby Info: (was: [Patch Available]) Many thanks to the reviewers for the help and good suggestions! I decided that the patch seems to be ready and so I've committed it to subversion as revision 472708. > Provide ALTER TABLE RENAME COLUMN functionality > --- > > Key: DERBY-1490 > URL: http://issues.apache.org/jira/browse/DERBY-1490 > 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.1.6, 10.1.2.1, > 10.1.3.1 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton > Fix For: 10.3.0.0 > > Attachments: 1490_cannot_patch.jpg, derby1490_v1_needMoreTests.diff, > renameColumn_v2_with_tests.diff, renameColumn_v3_after_review.diff, > renameColumn_v4_fix_error_message.diff, renameColumn_v5_with_schema_test.diff > > > Provide a way to rename a column in an existing table. Possible syntax could > be: > ALTER TABLE tablename RENAME COLUMN oldcolumn TO newcolumn; > Feature should properly handle the possibility that the column is currently > used in constraints, views, indexes, triggers, etc. -- 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-2018) NullPointerException in CREATE VIEW ... VALUES NULL;
[ http://issues.apache.org/jira/browse/DERBY-2018?page=all ] Yip Ng updated DERBY-2018: -- Derby Info: [Patch Available] > NullPointerException in CREATE VIEW ... VALUES NULL; > > > Key: DERBY-2018 > URL: http://issues.apache.org/jira/browse/DERBY-2018 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 > Environment: Java 1.5.0_06-b05 >Reporter: Christian d'Heureuse > Assigned To: Yip Ng >Priority: Minor > Attachments: derby2018-trunk-diff01.txt, derby2018-trunk-stat01.txt > > > The following statement produces a NullPointerException: >CREATE VIEW v1 (f1) AS VALUES NULL; > Stack trace: > > 2006-10-30 12:39:31.750 GMT: > Booting Derby version The Apache Software Foundation - Apache Derby - > 10.2.1.6 - (452058): instance c013800d-010e-993b-512f-0012f418 > on database directory C:\temp_sys\temp_Derby_TestErr_db > Database Class Loader started - derby.database.classpath='' > 2006-10-30 12:39:38.484 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), > (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Cleanup > action starting > 2006-10-30 12:39:38.484 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), > (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Failed > Statement is: CREATE VIEW v1 (f1) AS VALUES NULL > java.lang.NullPointerException > at > org.apache.derby.impl.sql.catalog.SYSCOLUMNSRowFactory.makeRow(Unknown Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorArray(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateViewConstantAction.executeConstantAction(Unknown > Source) > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown > Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) > at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) > at org.apache.derby.tools.ij.main(Unknown Source) -- 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-2018) NullPointerException in CREATE VIEW ... VALUES NULL;
[ http://issues.apache.org/jira/browse/DERBY-2018?page=all ] Yip Ng updated DERBY-2018: -- Attachment: derby2018-trunk-stat01.txt derby2018-trunk-diff01.txt Attaching derby2018-trunk-diff01.txt. This is a simple fix where it catches untyped null in CreateViewNode at bind phase (same logic as CursorNode) and throws the exception. derbyall passes except for the following tests which already failed before this patch. derbyall/derbynetclientmats/derbynetclientmats.fail:junitTests/derbyNet/CompatibilityTest.java derbyall/derbynetclientmats/derbynetmats.fail:derbynet/ShutDownDBWhenNSShutsDownTest.junit derbyall/derbynetmats/derbynetmats.fail:derbynet/ShutDownDBWhenNSShutsDownTest.junit JUnit suite passes. > NullPointerException in CREATE VIEW ... VALUES NULL; > > > Key: DERBY-2018 > URL: http://issues.apache.org/jira/browse/DERBY-2018 > Project: Derby > Issue Type: Bug > Components: SQL >Affects Versions: 10.2.1.6 > Environment: Java 1.5.0_06-b05 >Reporter: Christian d'Heureuse > Assigned To: Yip Ng >Priority: Minor > Attachments: derby2018-trunk-diff01.txt, derby2018-trunk-stat01.txt > > > The following statement produces a NullPointerException: >CREATE VIEW v1 (f1) AS VALUES NULL; > Stack trace: > > 2006-10-30 12:39:31.750 GMT: > Booting Derby version The Apache Software Foundation - Apache Derby - > 10.2.1.6 - (452058): instance c013800d-010e-993b-512f-0012f418 > on database directory C:\temp_sys\temp_Derby_TestErr_db > Database Class Loader started - derby.database.classpath='' > 2006-10-30 12:39:38.484 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), > (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Cleanup > action starting > 2006-10-30 12:39:38.484 GMT Thread[main,5,main] (XID = 122), (SESSIONID = 0), > (DATABASE = c:\temp_sys\temp_Derby_TestErr_db), (DRDAID = null), Failed > Statement is: CREATE VIEW v1 (f1) AS VALUES NULL > java.lang.NullPointerException > at > org.apache.derby.impl.sql.catalog.SYSCOLUMNSRowFactory.makeRow(Unknown Source) > at > org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorArray(Unknown > Source) > at > org.apache.derby.impl.sql.execute.CreateViewConstantAction.executeConstantAction(Unknown > Source) > at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown > Source) > at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown > Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source) > at org.apache.derby.impl.tools.ij.ij.executeImmediate(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.doCatch(Unknown Source) > at org.apache.derby.impl.tools.ij.utilMain.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.go(Unknown Source) > at org.apache.derby.impl.tools.ij.Main.mainCore(Unknown Source) > at org.apache.derby.impl.tools.ij.Main14.main(Unknown Source) > at org.apache.derby.tools.ij.main(Unknown Source) -- 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-2052) JDBC.assertRowInResultSet compares the wrong value if using trimmed strings and a SMALLINT column exists.
[ http://issues.apache.org/jira/browse/DERBY-2052?page=all ] Daniel John Debrunner closed DERBY-2052. Fix Version/s: 10.3.0.0 Resolution: Fixed > JDBC.assertRowInResultSet compares the wrong value if using trimmed strings > and a SMALLINT column exists. > - > > Key: DERBY-2052 > URL: http://issues.apache.org/jira/browse/DERBY-2052 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Daniel John Debrunner > Assigned To: Daniel John Debrunner > Fix For: 10.3.0.0 > > Attachments: derby2052_diff.txt > > > There is a bug in assertRowInResultSet where a path through the loop does not > set the variable obj. > This leads to it being compared with the previous value. > Using locally scoped variables within the loop would have most likely caught > this bug at development time. > Then the compiler sees that obj has one uninitialzed path through the code > and throws an error. -- 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-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[
http://issues.apache.org/jira/browse/DERBY-638?page=comments#action_12448320 ]
Deepa Remesh commented on DERBY-638:
I now see the current implementation will commit the transaction in all cases.
The exception was indeed misleading and DERBY-638-v2.diff is more correct. I
agree it will be good to fix this misleading exception and open separate JIRAs
for the other two issues. It will be good if the repro can be included as a
test case in the patch.
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, d638_repro2.java, d638_repro3.java,
> DERBY-638-v2.diff, DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2063) derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform
derbynet/ShutDownDBWhenNSShutsDownTest.junit fails with IBM JVM 142 and 15 on Linux platform Key: DERBY-2063 URL: http://issues.apache.org/jira/browse/DERBY-2063 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.1.8 Reporter: Manjula Kutty *** Start: ShutDownDBWhenNSShutsDownTest jdk1.5.0 DerbyNetClient derbynetmats:derbynetmats 2006-11-07 23:29:20 *** 0 add > .F. > There was 1 failure: > 1) > testEngineShutdownDoesNotTakeDownNS(org.apache.derbyTesting.functionTests.tests.derbynet.ShutDownDBWhenNSShutsDownTest)junit.framework.ComparisonFailure: > Engine shutdown expected: but was:<08001> > FAILURES!!! > Tests run: 2, Failures: 1, Errors: 0 Test Failed. -- 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-553) With JDK 1.5 signatures from signed jar in a database are not returned by Class.getSigners() when database in stored in a jar file.
[ http://issues.apache.org/jira/browse/DERBY-553?page=comments#action_12448306 ] Daniel John Debrunner commented on DERBY-553: - The Sun Java bug 6348368 has been closed as: Closed, duplicate of 6284489 However 6284489 is not visible. > With JDK 1.5 signatures from signed jar in a database are not returned by > Class.getSigners() when database in stored in a jar file. > --- > > Key: DERBY-553 > URL: http://issues.apache.org/jira/browse/DERBY-553 > Project: Derby > Issue Type: Bug > Components: Security, Services >Affects Versions: 10.1.1.0 > Environment: JDK 1.5 >Reporter: Daniel John Debrunner >Priority: Minor > Attachments: cert15_repro.jar > > > See differences between the generic master file for lang/dcl.sql and the > jdk1.5 version for the return from the function EMC.GETSIGNERS. > NULL is incorrectly returned in JDK 1.5, while a valid signature description > is returned in JDK 1.3,1.4. > Will see if changes made for DERBY-538 resolve this. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2062) Need to filter out this line from the output with jcc 2.6.90. DB2ConnectionCorrelator: NF000001.GDBA.010EB568BF46
Need to filter out this line from the output with jcc 2.6.90. DB2ConnectionCorrelator: NF01.GDBA.010EB568BF46 - Key: DERBY-2062 URL: http://issues.apache.org/jira/browse/DERBY-2062 Project: Derby Issue Type: Bug Affects Versions: 10.0.2.1 Reporter: Manjula Kutty -- 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 Report - tinderbox_trunk15 472613 - Sun DBTG
[Auto-generated mail] *tinderbox_trunk15* 472613/2006-11-08 20:52:18 CET Failed TestsOK Skip Duration Platform --- *Jvm: 1.5* SunOS-5.10_i86pc-i386 3519516 2 121.12% derbyall 020182018 0 117.39% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/Limited/testSummary-472613.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/FailReports/472613.html --- Changes in http://dbtg.thresher.com/derby/test/tinderbox_trunk15/UpdateInfo/472613.txt ( All results in http://dbtg.thresher.com/derby/test/ )
[jira] Created: (DERBY-2061) derbynet/testProperties.java falis with IBM 142 on version 10.1
derbynet/testProperties.java falis with IBM 142 on version 10.1 --- Key: DERBY-2061 URL: http://issues.apache.org/jira/browse/DERBY-2061 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.1.3.1 Reporter: Manjula Kutty 12 del < Successfully Connected 12a12,16 > Giving up on wait, waited: 6 > java.lang.Exception: DRDA_NoIO.S:Could not connect to Derby Network Server on > host 127.0.0.1, port 1530. > org.apache.derby.drda.NetworkServerControl shutdown -p 1527 > org.apache.derby.drda.NetworkServerControl shutdown -p 1528 > org.apache.derby.drda.NetworkServerControl shutdown -p 1529 17 del < Testing start server by specifying system properties without values < First shutdown server started on default port by the test harness < org.apache.derby.drda.NetworkServerControl shutdown -p 1527 < -Dderby.drda.logConnections -Dderby.drda.traceAll -Dderby.drda.traceDirectory -Dderby.drda.keepAlive -Dderby.drda.timeSlice -Dderby.drda.host -Dderby.drda.portNumber -Dderby.drda.minThreads -Dderby.drda.maxThreads -Dderby.drda.startNetworkServer -Dderby.drda.debug org.apache.derby.drda.NetworkServerControl start < - listing properties -- < derby.drda.maxThreads=0 < derby.drda.keepAlive=true < derby.drda.minThreads=0 < derby.drda.portNumber=1527 < derby.drda.logConnections=false < derby.drda.timeSlice=0 < derby.drda.startNetworkServer=false < derby.drda.host=localhost < derby.drda.traceAll=false < Successfully Connected < org.apache.derby.drda.NetworkServerControl shutdown -p 1527 < End test Test Failed. -- 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-2060) SET CURRENT ISOLATION in ref.man refers java.sql.Connection.setTransactionLevel instead of java.sql.Connection.setTransactionIsolation
SET CURRENT ISOLATION in ref.man refers java.sql.Connection.setTransactionLevel instead of java.sql.Connection.setTransactionIsolation -- Key: DERBY-2060 URL: http://issues.apache.org/jira/browse/DERBY-2060 Project: Derby Issue Type: Bug Components: Documentation Reporter: Bernt M. Johnsen On SET CURRENT ISOLATION statement in the Derby refernce manual: "Issuing this command commits the current transaction, which is consistent with the java.sql.Connection.setTransactionLevel method." The correct method name is java.sql.Connection.setTransactionIsolation (java.sql.Connection.setTransactionLevel does not exist) BTW: setTransactionIsolation will commit the current transaction if called in the client driver but not in the embedded driver. See DERBY-638 -- 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-2059) derbynetmats/derbynetmats.fail:jdbcapi/resultset.java,derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java,derbynetmats/derbynetmats.fail:jdbcapi/parameterMapping.java are
derbynetmats/derbynetmats.fail:jdbcapi/resultset.java,derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java,derbynetmats/derbynetmats.fail:jdbcapi/parameterMapping.java are failing with JCC 2.8.47 with IBM JVM 142 and 15 on 10.1 -- Key: DERBY-2059 URL: http://issues.apache.org/jira/browse/DERBY-2059 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.1.3.1 Reporter: Manjula Kutty *** Start: LOBTest jdk1.4.2 DerbyNet derbynetmats:jdbcapi 2006-11-07 00:04:57 *** 45 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 45a45 > 1 getBytes ->Object': byte[] 68 del < 2 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 68a68 > 2 getBytes ->Object': byte[] 91 del < 3 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 91a91 > 3 getBytes ->Object': byte[] 607 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 607a607 > 1 getBytes ->Object': byte[] 630 del < 2 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 630a630 > 2 getBytes ->Object': byte[] 653 del < 3 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 653a653 > 3 getBytes ->Object': byte[] 1169 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1169a1169 > 1 getBytes ->Object': byte[] 1192 del < 2 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1192a1192 > 2 getBytes ->Object': byte[] 1215 del < 3 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1215a1215 > 3 getBytes ->Object': byte[] 1710 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1710a1710 > 1 getBytes ->Object': byte[] 1733 del < 2 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1733a1733 > 2 getBytes ->Object': byte[] 1756 del < 3 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 1756a1756 > 3 getBytes ->Object': byte[] 2251 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 2251a2251 > 1 getBytes ->Object': byte[] 2274 del < 2 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 2274a2274 > 2 getBytes ->Object': byte[] 2297 del < 3 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 2297a2297 > 3 getBytes ->Object': byte[] 2794 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 2794a2794 > 1 getBytes ->Object': byte[] 3347 del < 1 getBytes -> EXCEPTION (Invalid data conversion: Wrong result column type for requested conversion.) 3347a3347 > 1 getBytes ->Object': byte[] Test Failed. *** End: LOBTest jdk1.4.2 DerbyNet derbynetmats:jdbcapi 2006-11-07 00:05:15 *** * Diff file derbynetmats/DerbyNet/jdbcapi/parameterMapping.diff *** Start: parameterMapping jdk1.4.2 DerbyNet derbynetmats:jdbcapi 2006-11-07 00:06:51 *** 1256 del < getBytes=IC JDBC MATCH (INVALID) 1256a1256 > getBytes=0x33,0x32 was null false CLOUD EXT (OK) 1428 del < getBytes=IC JDBC MATCH (INVALID) 1428a1428 > getBytes=0x33,0x32 was null false CLOUD EXT (OK) 1600 del < getBytes=IC JDBC MATCH (INVALID) 1600a1600 > getBytes=0x33,0x32 was null false CLOUD EXT (OK) Test Fa
[jira] Updated: (DERBY-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[ http://issues.apache.org/jira/browse/DERBY-638?page=all ]
Bernt M. Johnsen updated DERBY-638:
---
Attachment: d638_repro3.java
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, d638_repro2.java, d638_repro3.java,
> DERBY-638-v2.diff, DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[
http://issues.apache.org/jira/browse/DERBY-638?page=comments#action_12448292 ]
Bernt M. Johnsen commented on DERBY-638:
Bryan: I propose that we on the short term (and in 10.2 and possibly 10.1) fix
the misleading exception which this report is about, but keep the difference.
And that the different behaviour will be fixed e.g. for 10.3
Deepa: The current implementation will commit the active transaction. The
exception is misleading, since there is no active transaction after
setTransactionIsolation in the client. Try out d638_repro3.java. I agree that
trying to make embedded and client behaviour similar is ideal, but neither of
my patches will actually fix that.
The JDBC spec just says that "If this method is called during a transaction,
the result is implementation-defined."
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, d638_repro2.java, DERBY-638-v2.diff,
> DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2058) derbyall/derbyall.fail:lang/groupBy.sql, derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql failed with wctme5.7 max libraries on version 10.2
derbyall/derbyall.fail:lang/groupBy.sql, derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql failed with wctme5.7 max libraries on version 10.2 Key: DERBY-2058 URL: http://issues.apache.org/jira/browse/DERBY-2058 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.1.8 Reporter: Manjula Kutty Priority: Minor The diff for the failed tests are : *** Start: groupBy jdk1.3.1 subset - 2.2 derbyall:derbylang 2006-11-04 09:29:36 *** 24 del < ij> -- group by position 24a24,25 > ij> -- group by constant. should compile but fail because > -- it is not a valid grouping expression. 26 del < ERROR 42X01: Syntax error: Encountered "1" at line 2, column 27. 26a27 > ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid > expression. If a SELECT list has a GROUP BY, the list may only contain valid > grouping expressions and valid aggregate expressions. 32 del < ERROR 42Y36: Column reference 'A' is invalid. For a SELECT list with a GROUP BY, the list may only contain grouping columns and valid aggregate expressions. 32a33 > ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid > expression. If a SELECT list has a GROUP BY, the list may only contain valid > grouping expressions and valid aggregate expressions. 34 del < ERROR 42Y36: Column reference 'A' is invalid. For a SELECT list with a GROUP BY, the list may only contain grouping columns and valid aggregate expressions. 34a35 > ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid > expression. If a SELECT list has a GROUP BY, the list may only contain valid > grouping expressions and valid aggregate expressions. 36 del < ERROR 42Y36: Column reference 'B' is invalid. For a SELECT list with a GROUP BY, the list may only contain grouping columns and valid aggregate expressions. 37 del < ij> -- columns in group by list must be unique 38 del < select a, b from t1 group by a, a; 39 del < ERROR 42Y19: 'A' appears multiple times in the GROUP BY list. Columns in the GROUP BY list must be unambiguous. 40 del < ij> select a, b from t1 group by a, t1.a; 41 del < ERROR 42Y19: 'A' appears multiple times in the GROUP BY list. Columns in the GROUP BY list must be unambiguous. 41a37 > ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid > expression. If a SELECT list has a GROUP BY, the list may only contain valid > grouping expressions and valid aggregate expressions. 50 del < ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid expression. If a SELECT list has a GROUP BY, the list may only contain grouping columns and valid aggregate expressions. 50a46 > ERROR 42Y30: The SELECT list of a grouped query contains at least one invalid > expression. If a SELECT list has a GROUP BY, the list may only contain valid > grouping expressions and valid aggregate expressions. 59 del < ERROR 42X01: Syntax error: Encountered "?" at line 2, column 27. 59a55 > ERROR 42X01: Syntax error: ?. Test Failed. 52 del < ERROR 38000: Se he generado la excepci EnC:>243< n 'java.sql.SQLException: La tabla 'IEP.NOTABLE' no existe.' al evaluar una expresi EnC:>243< n. 53 del < ERROR 42X05: La tabla 'IEP.NOTABLE' no existe. 53a52,53 > ERROR 38000: Se he generado la excepci EnC:>243< n 'java.sql.SQLException: La > tabla/vista 'IEP.NOTABLE' no existe.' al evaluar una expresi EnC:>243< n. > ERROR 42X05: La tabla/vista 'IEP.NOTABLE' no existe. 138 del < ERROR XIE0M: La tabla 'IEP.NOTABLE' no existe. 138a138 > ERROR XIE0M: La tabla 'IEP.NOTABLE' no existe. 142 del < ERROR XIE0M: La tabla '.T1' no existe. 142a142 > ERROR XIE0M: La tabla '.T1' no existe. 223 del < ERROR XIE0M: La tabla 'SESSION.TEMP2' no existe. 223a223 > ERROR XIE0M: La tabla 'SESSION.TEMP2' no existe. 225 del < ERROR 42X05: La tabla 'SESSION.TEMP2' no existe. 225a225 > ERROR 42X05: La tabla/vista 'SESSION.TEMP2' no existe. 317 del < ERROR 38000: Se he generado la excepci EnC:>243< n 'java.sql.SQLException: 'SYS.SYSTABLES' es una tabla del sistema. Los usuarios no tienen permitido modificar el contenido de esta tabla.' al evaluar una expresi EnC:>243< n. 318 del < ERROR 42Y25: 'SYS.SYSTABLES' es una tabla del sistema. Los usuarios no tienen permitido modificar el contenido de esta tabla. 318a317,318 > ERROR 38000: Se he generado la excepci EnC:>243< n 'java.sql.SQLException: > 'SYS.SYSTABLES' es una tabla del sistema. Los usuarios no tienen permitido > modificar el contenido de esta tabla.' al evaluar una expresi EnC:>243< n. > ER
[jira] Commented: (DERBY-2056) junitTests/derbyNet/CompatibilityTest.java fails with IBM JVM 142 and 15 on both Windows and Linux platforms
[ http://issues.apache.org/jira/browse/DERBY-2056?page=comments#action_12448264 ] Knut Anders Hatlen commented on DERBY-2056: --- It fails with Sun's JVM too. See http://dbtg.thresher.com/derby/test/tinderbox_trunk15/jvm1.5/testing/testlog/SunOS-5.10_i86pc-i386/472392-derbyall_diff.txt > junitTests/derbyNet/CompatibilityTest.java fails with IBM JVM 142 and 15 on > both Windows and Linux platforms > > > Key: DERBY-2056 > URL: http://issues.apache.org/jira/browse/DERBY-2056 > Project: Derby > Issue Type: Bug > Components: Regression Test Failure >Affects Versions: 10.2.1.8 >Reporter: Manjula Kutty > > This test fails with the following diff > *** Start: CompatibilityTest jdk1.4.2 DerbyNetClient > derbynetclientmats:derbynetclientmats 2006-11-03 21:15:46 *** > 0 add > > Exception in thread "main" java.lang.ExceptionInInitializerError > > Caused by: java.security.AccessControlException: access denied > > (java.io.FilePermission C:\Documents and > > Settings\cloudtest\junit.properties read) > > ... 2 more > Test Failed. -- 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-2057) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or implementation error on its arguments.
[ http://issues.apache.org/jira/browse/DERBY-2057?page=all ] Yip Ng updated DERBY-2057: -- Component/s: Miscellaneous (was: Store) > SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or implementation error > on its arguments. > --- > > Key: DERBY-2057 > URL: http://issues.apache.org/jira/browse/DERBY-2057 > Project: Derby > Issue Type: Bug > Components: Documentation, Javadoc, Miscellaneous >Affects Versions: 10.2.1.6, 10.3.0.0 > Environment: Any >Reporter: Yip Ng > > There seems to be an error on the SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE > documentation or the implementation itself when passing the following > arguments: > PURGE_ROWS > If PURGE_ROWS is set to a *non-zero* value, then a single pass is made > through the table which will purge committed deleted rows from the table. > > DEFRAGMENT_ROWS > If DEFRAGMENT_ROWS is set to a *non-zero* value, then a single defragment > pass is made which will move existing rows from the end of the table towards > the front of the table. > > TRUNCATE_END > If TRUNCATE_END is set to a *non-zero* value, then all contiguous pages > at the end of the table will be returned to the operating system. > > The implementation only checks if the above arguments are 1s. > org.apache.derby.iapi.db.OnlineCompress.compressTable( > schema, > tablename, > (purgeRows == 1), > (defragementRows == 1), > (truncateEnd == 1)); > ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2057) SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or implementation error on its arguments.
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or implementation error on its arguments. --- Key: DERBY-2057 URL: http://issues.apache.org/jira/browse/DERBY-2057 Project: Derby Issue Type: Bug Components: Documentation, Javadoc, Store Affects Versions: 10.2.1.6, 10.3.0.0 Environment: Any Reporter: Yip Ng There seems to be an error on the SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE documentation or the implementation itself when passing the following arguments: PURGE_ROWS If PURGE_ROWS is set to a *non-zero* value, then a single pass is made through the table which will purge committed deleted rows from the table. DEFRAGMENT_ROWS If DEFRAGMENT_ROWS is set to a *non-zero* value, then a single defragment pass is made which will move existing rows from the end of the table towards the front of the table. TRUNCATE_END If TRUNCATE_END is set to a *non-zero* value, then all contiguous pages at the end of the table will be returned to the operating system. The implementation only checks if the above arguments are 1s. org.apache.derby.iapi.db.OnlineCompress.compressTable( schema, tablename, (purgeRows == 1), (defragementRows == 1), (truncateEnd == 1)); ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2056) junitTests/derbyNet/CompatibilityTest.java fails with IBM JVM 142 and 15 on both Windows and Linux platforms
junitTests/derbyNet/CompatibilityTest.java fails with IBM JVM 142 and 15 on both Windows and Linux platforms Key: DERBY-2056 URL: http://issues.apache.org/jira/browse/DERBY-2056 Project: Derby Issue Type: Bug Components: Regression Test Failure Affects Versions: 10.2.1.8 Reporter: Manjula Kutty This test fails with the following diff *** Start: CompatibilityTest jdk1.4.2 DerbyNetClient derbynetclientmats:derbynetclientmats 2006-11-03 21:15:46 *** 0 add > Exception in thread "main" java.lang.ExceptionInInitializerError > Caused by: java.security.AccessControlException: access denied > (java.io.FilePermission C:\Documents and Settings\cloudtest\junit.properties > read) > ... 2 more Test Failed. -- 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-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=all ] Daniel John Debrunner updated DERBY-2048: - Derby Info: (was: [Patch Available]) Committed revision 472613 - Thanks Yip > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2048-trunk-diff01.txt, derby2048-trunk-diff02.txt, > derby2048-trunk-stat01.txt > > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=all ] Yip Ng updated DERBY-2048: -- Attachment: derby2048-trunk-diff02.txt Attaching derby2048-trunk-diff02.txt with Dan's suggestion on clarifying the method name and javadoc comments. > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2048-trunk-diff01.txt, derby2048-trunk-diff02.txt, > derby2048-trunk-stat01.txt > > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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] Commented: (DERBY-2006) Add JUnit and JUnitReport task as a target in Ant script
Myrna van Lunteren (JIRA) wrote: [ http://issues.apache.org/jira/browse/DERBY-2006?page=comments#action_12448010 ] Myrna van Lunteren commented on DERBY-2006: --- I played with this for (quite) a while, but with the current version I use to test j2ME on Windows (wctme5.7 jcl foundation class), which has a problem with security manager (see: http://wiki.apache.org/db-derby/JunitVmIssues#head-0916dd3630b0667e49460439fbd041c720d93eaf), I have to jump through quite a few hoops to get things working. In fact, I didn't actually get things working. I've gotten as far as hard-coding in a number of jvmargs in build.xml: But this results in: [junit] Exception in thread "main" java.security.AccessControlException: Access denied (java.lang.RuntimePermission setIO ) [junit] at java.security.AccessController.checkPermission(AccessController.java:74) [junit] at java.lang.SecurityManager.checkPermission(SecurityManager.java:612) [junit] at java.lang.System.setOut(System.java:76) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:309) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:672) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:567) [junit] Test org.apache.derbyTesting.functionTests.tests.tools._Suite FAILED [antcall] Exiting C:\derbyt\svn2\trunk\build.xml. and the resulting _Suite.xml files are empty. I suspect my specification of either the policy file or derby.system.home is off... Anyways, this issue is closed, I think for now I'll just conclude that the ant target doesn't work well with wctme5.7 - foundation. The JUnit setup sets some additional properties for the ant and junit jars that you don't seem to have set above. derbyTesting.antjunit derbyTesting.junit You probably need to set those as well. You can also remove this one: ij.dataSource Junit does not use ij to get its connections. Dan.
[jira] Commented: (DERBY-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=comments#action_12448243 ] Daniel John Debrunner commented on DERBY-2048: -- Cool, interesting approach. Might be better to be clear that objects is really tables here, ie. compressTables(), COMPRESS_OBJECTS, since only tables are the only objects that can be compressed. > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2048-trunk-diff01.txt, derby2048-trunk-stat01.txt > > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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
[RESULT] [VOTE] Myrna Van Lunteren as a committer
On 11/2/06, Andrew McIntyre <[EMAIL PROTECTED]> wrote: I am proposing that we add Myrna Van Lunteren ([EMAIL PROTECTED]) as a committer for Derby. The vote passes with 28 +1 votes: +1: Andrew McIntyre Bryan Pendleton Rajesh Kartha Rick Hillegas Lance Andersen Øystein Grøvlen Suresh Thalamati Sunitha Kambhampati Mamta Satoor Mike Matrigali David Van Couvering Yip Ng Daniel John Debrunner Henri van de Scheur Army Bernt M. Johnsen Knut Anders Hatlen Jean T. Anderson Stanley Bradbury Craig L Russell Kristian Waagan Olav Sandstaa Fernanda Pizzorno Ole Solberg Tomohito Nakayama John Embretsen Kim Haase Manjula G Kutty andrew
[jira] Updated: (DERBY-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=all ] Yip Ng updated DERBY-2048: -- Derby Info: [Patch Available] > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2048-trunk-diff01.txt, derby2048-trunk-stat01.txt > > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=all ] Yip Ng updated DERBY-2048: -- Attachment: derby2048-trunk-stat01.txt derby2048-trunk-diff01.txt Attaching proposal patch derby2048-trunk-diff01.txt to fix the ordering diff problem. Add an additional cleanup step(compression) to cleanDatabase() method in java/testing/org/apache/derbyTesting/junit/CleanDatabaseTestSetup.java. After objects removal is performed via removeObjects(), object compression is performed in the new compressObjects() method on the SYS.SYSDEPENDS to compact the system table. (Currently it only compress this system table.) JUnit suite passes. > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > Attachments: derby2048-trunk-diff01.txt, derby2048-trunk-stat01.txt > > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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-2048) LangScripts JUnit test fails in views.sql
[ http://issues.apache.org/jira/browse/DERBY-2048?page=all ] Yip Ng reassigned DERBY-2048: - Assignee: Yip Ng > LangScripts JUnit test fails in views.sql > - > > Key: DERBY-2048 > URL: http://issues.apache.org/jira/browse/DERBY-2048 > Project: Derby > Issue Type: Bug > Components: Test >Affects Versions: 10.3.0.0 > Environment: Windows XP >Reporter: Yip Ng > Assigned To: Yip Ng > > LangScripts JUnit test fails in views.sql > There was 1 failure: > 1) views(org.apache.derbyTesting.functionTests.tests.lang.LangScripts > )junit.fram > ework.ComparisonFailure: Output at line 104 expected:<...T1' because VIEW > 'SV[1]' is dependent on th...> but was:<...T1' because VIEW 'SV[2]' is > dependent on th...> > at > org.apache.derbyTesting.functionTests.util.CanonTestCase.compareCanon(CanonTestCase.java:100) > at > org.apache.derbyTesting.functionTests.util.ScriptTestCase.runTest(ScriptTestCase.java:117) > at > org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:76) > at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) > at junit.extensions.TestSetup$1.protect(TestSetup.java:21) > at junit.extensions.TestSetup.run(TestSetup.java:25) > FAILURES!!! > Tests run: 2016, Failures: 1, Errors: 0 > Some observations: > If org.apache.derbyTesting.functionTests.tests.lang.LangScripts is used to > run views.sql as a single test, then it ran smoothly without a problem. > . > Time: 7.109 > OK (1 test) > But if views.sql is run as part of a suite, then the ordering diff occurs. -- 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-2001) Add DITA templates for the 3 topic types into the trunk
[ http://issues.apache.org/jira/browse/DERBY-2001?page=comments#action_12448210 ] Kim Haase commented on DERBY-2001: -- These are great, Laura. Just a few comments. Concept template: Great -- only a couple of spelling items. TOPIC TITLE: Spelling is "gerund" NOTES: Spelling is "label" Reference template: Also fine -- formatting nits only. REFSYN: Missing word? "that syntax or signature content" should be "that contains syntax or signature content"? PARAGRAPHS: need a linebreak before this comment, and again before . Also, is there a reason for the xref tag (with no space after the period)? Its presence is a bit confusing. TABLE: need a linebreak before this comment, and again before NOTES: need a linebreak before this comment, and again before Task template: Also nearly perfect. Are there some stray spaces at the top of the file? TOPIC TITLE: I think there is a stray sentence that should be cut? "The title for short description is the first paragraph in the topic and can be used as an abstract." Unless some other text was intended. > Add DITA templates for the 3 topic types into the trunk > --- > > Key: DERBY-2001 > URL: http://issues.apache.org/jira/browse/DERBY-2001 > Project: Derby > Issue Type: Bug > Components: Documentation >Affects Versions: 10.2.1.6 >Reporter: Laura Stewart > Assigned To: Laura Stewart > Fix For: 10.2.1.8 > > Attachments: concept_template.dita, concept_template.dita, > derby2001_1.diff, derby2001_1.stat, derby2001_2.diff, derby2001_2.stat, > reference_template.dita, reference_template.dita, task_template.dita, > task_template.dita > > > Create templates for each of the DITA topic types - concept, reference, task > Add these templates to the Derby trunk so that anyone can use them. -- 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-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[ http://issues.apache.org/jira/browse/DERBY-638?page=all ]
Deepa Remesh updated DERBY-638:
---
Attachment: d638_repro2.java
Thanks Bernt for looking at this issue.
Patch1 seems better to me and will match more with the embedded implementation.
With patch1, we do not commit any other statements which could be executed in
the meantime. But with patch2, client driver will commit everything executed
before the call to setTransactionIsolation. This, I think is not expected when
we have explicitly set the connection's auto-commit to false.
I am attaching a modified repro 'd638_repro2.java' which executes some
statements after setting auto-commit to false and before the call to
setTransactionIsolation. With patch1, both embedded and client driver show
uncommitted transactions. With patch2, client driver commits everything.
However, it is not clear to me what the correct behaviour should be as the JDBC
spec only has recommendations for the implementation of setTransactionIsolation
method. But I think it will be good to keep embedded and client behaviour
similar.
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, d638_repro2.java, DERBY-638-v2.diff,
> DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[
http://issues.apache.org/jira/browse/DERBY-638?page=comments#action_12448196 ]
Bryan Pendleton commented on DERBY-638:
---
Hi Bernt, I haven't read your code, just trying to follow the comments, but:
are you proposing
to change the client to match the embedded behavior, or are you proposing to
change
embedded to match the client behavior (or maybe you're proposing some 3rd thing
entirely)?
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, DERBY-638-v2.diff, DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 472166 - Sun DBTG
[Auto-generated mail] *Daily* 472166/2006-11-07 18:00:09 MET Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 3527524 099.61% derbyall F:3,E:30922121900 087.69% org.apache.derbyTesting.functionTests.suites.All sol 4527523 0 429.85% derbyall F:1,E:043724371 0 .% org.apache.derbyTesting.functionTests.suites.All solN+1 3527524 0 115.38% derbyall F:1,E:043724371 0 104.20% org.apache.derbyTesting.functionTests.suites.All sparc 3527524 099.91% derbyall F:1,E:043724371 0 100.21% org.apache.derbyTesting.functionTests.suites.All win 3527524 0 149.27% derbyall F:1,E:043724371 0 100.00% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-472166.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.6/FailReports/472166.html *Jvm: 1.5* lin 1519518 2 100.16% derbyall F:1,E:020182017 0 103.99% org.apache.derbyTesting.functionTests.suites.All sol 1519518 2 107.69% derbyall F:1,E:020182017 0 101.40% org.apache.derbyTesting.functionTests.suites.All solN+1 1519518 2 120.44% derbyall F:1,E:020182017 0 102.78% org.apache.derbyTesting.functionTests.suites.All sparc 1519518 2 100.02% derbyall F:1,E:020182017 098.97% org.apache.derbyTesting.functionTests.suites.All win 1519518 2 159.31% derbyall F:1,E:020182017 0 .% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-472166.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.5/FailReports/472166.html *Jvm: 1.4* lin 1513512 4 100.11% derbyall F:1,E:020162015 0 105.57% org.apache.derbyTesting.functionTests.suites.All sol 1513512 4 103.51% derbyall F:1,E:020162015 0 .% org.apache.derbyTesting.functionTests.suites.All solN+1 1513512 4 120.81% derbyall F:1,E:020162015 0 100.25% org.apache.derbyTesting.functionTests.suites.All sparc 1513512 499.69% derbyall F:1,E:020162015 0 .% org.apache.derbyTesting.functionTests.suites.All win 1513512 490.77% derbyall F:1,E:020162015 0 101.35% org.apache.derbyTesting.functionTests.suites.All Details in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-472166.html Attempted failure analysis in http://dbtg.thresher.com/derby/test/Daily/jvm1.4/FailReports/472166.html --- Changes in http://dbtg.thresher.com/derby/test/Daily/UpdateInfo/472166.txt ( All results in http://dbtg.thresher.com/derby/test/ )
Documentation conventions, DITA, and the toolkit
This note is on a subject that could feed into the Guidelines doc, especially the parts about textual tags as opposed to structural tags. The Getting Started manual has a section called "Typographical conventions" (http://db.apache.org/derby/docs/dev/getstart/rgsdocs18277.html) that describes documentation conventions for the Derby manuals. It may need some refining. And then how to make the conventions happen in DITA leads to some toolkit questions. The goal of the section should be to describe the way things mostly are, so that we can try to encourage contributors to be consistent in the future. Fixing what's there now is a lower priority goal. I would appreciate your views, Laura, and those of anyone who's had longer experience with the docs than I have (most of you, I think). New terms in italic: this is fine. The DITA tag seems to translate into a tag in HTML. File and directory names in italic: this is a somewhat unusual convention in my experience (fixed-width is more common, I think), but I'd feel better about it if the documentation used it consistently. But even the Getting Started manual doesn't. I think this may be a toolkit issue, because Getting Started uses instead of , and the tag currently seems to translate into ordinary text font (, with no available css file to define the class). (The 3 css files that are copied into the output directory don't define this class.) Dictionary objects in italic: These are things stored in the database (tables, etc.). Italic also seems to be used generally for things like property names, Java object, interface, and method names, identifiers, and other code objects (which I'm also more used to seeing in fixed-width). I notice again that in the DITA source this is generally done with rather than semantic tagging, probably because there is no suitable semantic tag. One odd thing is that these objects are sometimes in fixed-width italic and sometimes plain italic, often within the same sentence or paragraph. (See, for example, "java.*, javax.*" in http://db.apache.org/derby/docs/dev/devguide/cdevdeploy15818.html, the second sentence in http://db.apache.org/derby/docs/dev/devguide/tdevdvlp14496.html, or http://db.apache.org/derby/docs/dev/devguide/cdevspecial16181.html.) I'm not sure why. Replaceable items: this is fine too, and the DITA tag does this job; it translates into in HTML. However, the syntax statement in the table is in fixed-width plain, when fixed-width bold is more usual. Probably some other things for which italic is used should be added to the table. These include book titles and section references; the tag works for these. (I would have added words that are emphasized, but DITA doesn't seem to believe in emphasis; there is no tag equivalent to HTML -- which actually is what DITA tags are translated into.) A number of items are listed as "Bold and/or fixed-width." This seems to give more leeway than is usual, though I gather it is meant to be more descriptive than prescriptive. However, there seems to be some consistency in how these are used in the books (I think you may have worked on making this so), so the descriptions could be narrowed in most cases. SQL examples: These seem to be nearly always fixed-width bold. is commonly used for examples. This translates into . Java application examples: These are less consistent -- sometimes fixed-width bold (in the Ref Manual) and sometimes fixed-width but not bold (in the Dev Guide and Admin Guide). I have to say I prefer the plain fixed-width, but if there is a much larger volume of text currently in fixed-width bold it would make sense to go with that. Things you type in a command prompt: These usually seem to be fixed-width bold. translates into , which is fixed-width but not bold, so when you use it you have to add a tag. This is also the case with . Comments within examples: These are usually fixed-width bold, too, when the SQL examples are. Sometimes with Java examples I have seen the comment in bold but the code in plain fixed-width (http://db.apache.org/derby/docs/dev/devguide/rdevconcepts88082.html). This has the merit of differentiating comments from code, but is more work for the writer. SQL keywords (commands) in all caps: this is fine (no DITA tags). It might be good to mention command syntax, which usually seems to be in fixed-width bold, with the replaceable items in fixed-width bold italic (using a ). There is no doc convention listed for commands that are not SQL commands, like ij, sysinfo, java, and the like. Possibly as a result, there's not much consistency in how these are done. I notice that the DITA tag translates into plain text -- in HTML it comes out as , but this translates into nothing. So these commands are sometimes in tags, sometimes in plain text, and occasionally in bold. They don't seem to be in italic, though. We could file a bug to get to translate into something (my inclination would be fixed-width, though italics would be more consis
[jira] Updated: (DERBY-2055) Add execution of the schema scripts for order entry
[ http://issues.apache.org/jira/browse/DERBY-2055?page=all ] Sunitha Kambhampati updated DERBY-2055: --- Component/s: Test Fix Version/s: 10.3.0.0 Priority: Minor (was: Major) Derby Info: [Patch Available] > Add execution of the schema scripts for order entry > --- > > Key: DERBY-2055 > URL: http://issues.apache.org/jira/browse/DERBY-2055 > Project: Derby > Issue Type: Sub-task > Components: Test >Reporter: Sunitha Kambhampati > Assigned To: Sunitha Kambhampati >Priority: Minor > Fix For: 10.3.0.0 > > Attachments: derby2055.diff.txt > > -- 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-2055) Add execution of the schema scripts for order entry
[ http://issues.apache.org/jira/browse/DERBY-2055?page=all ] Sunitha Kambhampati updated DERBY-2055: --- Attachment: derby2055.diff.txt This patch 1) Adds a new class Load.java to execute the schema scripts for OE within the junit framework. 2) Adds a new utility method to BaseJDBCTestCase to take a resource name and execute it using runScript. Some things to note: -- This test is not enabled to run currently as part of any other suite. -- Posting this patch as a first step to test the schema scripts etc. -- Running the Load test assumes that the database is clean of OE schema. I have not added the CleanDatabaseTestSetup because currently we do not want the load to clean itself up as this is still in development phase. To run, do: java junit.textui.TestRunner org.apache.derbyTesting.system.oe.run.Load svn stat: A java\testing\org\apache\derbyTesting\system\oe\run A java\testing\org\apache\derbyTesting\system\oe\run\Load.java M java\testing\org\apache\derbyTesting\junit\BaseJDBCTestCase.java Can someone please review/commit this. Thanks. > Add execution of the schema scripts for order entry > --- > > Key: DERBY-2055 > URL: http://issues.apache.org/jira/browse/DERBY-2055 > Project: Derby > Issue Type: Sub-task > Components: Test >Reporter: Sunitha Kambhampati > Assigned To: Sunitha Kambhampati > Fix For: 10.3.0.0 > > Attachments: derby2055.diff.txt > > -- 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-2050) Manipulating CachedItems could be more efficient
[ http://issues.apache.org/jira/browse/DERBY-2050?page=all ] Dyre Tjeldvoll updated DERBY-2050: -- Attachment: derby-2050.v2.diff New patch which - restores the deleted comment - removes unintended white space changes - restores the deleted final keywords Deletion was not intentional. I wanted to remove the final keywords that I had added myself, and did not notice that I removed some of the existing ones. I decided to remove the final keywords I which I had added since I noticed that the class itself was declared final. Is there some added benefit to declaring methods in a final class as final? > Manipulating CachedItems could be more efficient > > > Key: DERBY-2050 > URL: http://issues.apache.org/jira/browse/DERBY-2050 > Project: Derby > Issue Type: Improvement > Components: Performance >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2050.diff, derby-2050.stat, derby-2050.v2.diff > > > CachedItem's state is currently recorded in bit fields of an integer > variable. Changing this to 6 boolean member variables reduces cpu usage. -- 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-2054) Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test
[ http://issues.apache.org/jira/browse/DERBY-2054?page=comments#action_12448178 ] Tomohito Nakayama commented on DERBY-2054: -- Hello. I remember OwnServerTests_app.properties which was needed only for OwnServerTests.java. I think it also should be removed in your patch. http://svn.apache.org/repos/asf/db/derby/code/trunk/java/testing/org/apache/derbyTesting/functionTests/tests/junitTests/derbyNet/OwnServerTests_app.properties > Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test > - > > Key: DERBY-2054 > URL: http://issues.apache.org/jira/browse/DERBY-2054 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan >Priority: Minor > Attachments: derby-2054-preview.diff > > > The test 'derbynet/SuicideOfStreaming' should be rewritten to a JUnit test > more in line with our newly created test system. > It is one of the last tests still being run from the deprecated > 'tests/junitTests/' directory, through a wrapper class. -- 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-2055) Add execution of the schema scripts for order entry
Add execution of the schema scripts for order entry --- Key: DERBY-2055 URL: http://issues.apache.org/jira/browse/DERBY-2055 Project: Derby Issue Type: Sub-task Reporter: Sunitha Kambhampati Assigned To: Sunitha Kambhampati -- 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 (14 issues) Subscriber: derby-dev Key Summary DERBY-638 setTransactionIsolation behaviour in network client driver is different from that of embedded driver http://issues.apache.org/jira/browse/DERBY-638 DERBY-2042 Provide documentation for new RENAME COLUMN statement http://issues.apache.org/jira/browse/DERBY-2042 DERBY-1980 Web site - Documentation - Add a new page with writing guidelines http://issues.apache.org/jira/browse/DERBY-1980 DERBY-1490 Provide ALTER TABLE RENAME COLUMN functionality http://issues.apache.org/jira/browse/DERBY-1490 DERBY-2001 Add DITA templates for the 3 topic types into the trunk http://issues.apache.org/jira/browse/DERBY-2001 DERBY-2000 A SecurityManager is not always installed when running JUnit tests/suites http://issues.apache.org/jira/browse/DERBY-2000 DERBY-1972 Working With Derby needs some formatting fixes and other minor cleanup http://issues.apache.org/jira/browse/DERBY-1972 DERBY-2030 'set schema sys' followed by 'show tables' does not show tables in sys schema http://issues.apache.org/jira/browse/DERBY-2030 DERBY-1693 Out of Memory Error with derby.language.logStatementText=true http://issues.apache.org/jira/browse/DERBY-1693 DERBY-1808 [PATCH] Inbuilt functions SIGN, SQRT, RAND, RANDOM, COSH, SINH and TANH http://issues.apache.org/jira/browse/DERBY-1808 DERBY-2009 Modify links to reflect that Sun DBTG test reports have moved to dbtg.thresher.com http://issues.apache.org/jira/browse/DERBY-2009 DERBY-1938 Add support for setObject(, null) http://issues.apache.org/jira/browse/DERBY-1938 DERBY-963 Allow user friendly string values for security mechanism in client connection url. http://issues.apache.org/jira/browse/DERBY-963 DERBY-646 In-memory backend storage support http://issues.apache.org/jira/browse/DERBY-646
[jira] Updated: (DERBY-2054) Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test
[ http://issues.apache.org/jira/browse/DERBY-2054?page=all ] Kristian Waagan updated DERBY-2054: --- Attachment: derby-2054-preview.diff 'derby-2054-preview.diff' is the first attempt at rewriting SuicideOfStreaming. It is kind of special, since it uses a property inside a sanity manager block in the Derby code to generate an exception on the server. There is also the matter of only returning a suite with tests if Derby is built in sane mode (see the suite-method). Please have a look at the suggested test, and read the comments in the code. The diffs of the two old files implementing this test are included for reference. I will post another patch shortly, which will add a _Suite in the derbynet directory and fix a few other small things. > Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test > - > > Key: DERBY-2054 > URL: http://issues.apache.org/jira/browse/DERBY-2054 > Project: Derby > Issue Type: Test > Components: Test >Affects Versions: 10.3.0.0 >Reporter: Kristian Waagan > Assigned To: Kristian Waagan >Priority: Minor > Attachments: derby-2054-preview.diff > > > The test 'derbynet/SuicideOfStreaming' should be rewritten to a JUnit test > more in line with our newly created test system. > It is one of the last tests still being run from the deprecated > 'tests/junitTests/' directory, through a wrapper class. -- 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-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[ http://issues.apache.org/jira/browse/DERBY-638?page=all ]
Bernt M. Johnsen updated DERBY-638:
---
Attachment: DERBY-638-v2.diff
Simpler, cleaner, more correct.
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, DERBY-638-v2.diff, DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DERBY-2054) Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test
Rewrite 'derbynet/SuicideOfStreaming' to a JUnit test - Key: DERBY-2054 URL: http://issues.apache.org/jira/browse/DERBY-2054 Project: Derby Issue Type: Test Components: Test Affects Versions: 10.3.0.0 Reporter: Kristian Waagan Assigned To: Kristian Waagan Priority: Minor The test 'derbynet/SuicideOfStreaming' should be rewritten to a JUnit test more in line with our newly created test system. It is one of the last tests still being run from the deprecated 'tests/junitTests/' directory, through a wrapper class. -- 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-2050) Manipulating CachedItems could be more efficient
[ http://issues.apache.org/jira/browse/DERBY-2050?page=comments#action_12448155 ] Knut Anders Hatlen commented on DERBY-2050: --- I haven't tested the performance impact, but I definitely think the patch makes the code cleaner. A couple of small comments: * The final keyword has been removed from the definition of isKept() and isValid(). Was that intentional? * The comment in settingIdentityComplete() was deleted, but I think it's still relevant. * White-space changes in unkeep() and use(). Blanks inserted in front of the tabs. > Manipulating CachedItems could be more efficient > > > Key: DERBY-2050 > URL: http://issues.apache.org/jira/browse/DERBY-2050 > Project: Derby > Issue Type: Improvement > Components: Performance >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2050.diff, derby-2050.stat > > > CachedItem's state is currently recorded in bit fields of an integer > variable. Changing this to 6 boolean member variables reduces cpu usage. -- 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-638) setTransactionIsolation behaviour in network client driver is different from that of embedded driver
[
http://issues.apache.org/jira/browse/DERBY-638?page=comments#action_12448139 ]
Bernt M. Johnsen commented on DERBY-638:
After some investigation, I have found that this is actually three separate
issues:
1) There is a difference between the embedded driver where
setTransacionIsolation does not cause a commit and the nework client where
setTransactionIsolation causes a commit (Side effect of using SET CURRENT
ISOLATION).
2) setTransactionIsolation in the network client does not do the proper
householding activity wrt. this is an implicit commit and that
Statement.execute("SET CURRENT ISOLATION...") is used to implement it, and
hence you get the exception documented in the description
3) (Small) The SQLState and error message is different when Connection.close()
is done on an active transaction
Suggest that 1) & 3) is placed into separate issues while this issue is related
to 2) which is the short term fix for the reported exception.
BTW: I think the attached patch si not sufficient in the general case, where
there may be some open transaction when setTranascationIsolation is called, and
that transaction is implicitely committed.
> setTransactionIsolation behaviour in network client driver is different from
> that of embedded driver
>
>
> Key: DERBY-638
> URL: http://issues.apache.org/jira/browse/DERBY-638
> Project: Derby
> Issue Type: Bug
> Components: Network Client
>Affects Versions: 10.2.1.6
>Reporter: Deepa Remesh
> Assigned To: Bernt M. Johnsen
> Attachments: d638.java, DERBY-638.diff
>
>
> When autocommit is set to false, a call to setTransactionIsolation using
> client driver does not end the transaction when the method exits. When a
> close() is called on the conection, it throws an exception.
> Running the code below:
>conn.setAutoCommit(false);
>conn.setTransactionIsolation(Connection.TRANSACTION_READ_COMMITTED);
>try{
>conn.close();
>}catch(SQLException se){
>System.out.println("Got exception when closing the
> connection");
>se.printStackTrace();
>}
> with client driver gives:
> Got exception when closing the connection
> org.apache.derby.client.am.SqlException: java.sql.Connection.close()
> requested while a transaction is in progress on the connection.The
> transaction remains active, and the connection cannot be closed.
> with embedded driver, it works okay and does not throw any exception.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-2050) Manipulating CachedItems could be more efficient
[ http://issues.apache.org/jira/browse/DERBY-2050?page=all ] Dyre Tjeldvoll updated DERBY-2050: -- Attachment: derby-2050.diff derby-2050.stat Seems like this change was possibly more controversial than I thought, but I'm attaching a patch anyway. Maybe those who are interested can look at the patch. Personally I found it very enlightening to compare the bytecode (using javap) generated for bitfield access with that generated for access to booleans . > Manipulating CachedItems could be more efficient > > > Key: DERBY-2050 > URL: http://issues.apache.org/jira/browse/DERBY-2050 > Project: Derby > Issue Type: Improvement > Components: Performance >Affects Versions: 10.2.1.6 >Reporter: Dyre Tjeldvoll >Priority: Trivial > Fix For: 10.3.0.0 > > Attachments: derby-2050.diff, derby-2050.stat > > > CachedItem's state is currently recorded in bit fields of an integer > variable. Changing this to 6 boolean member variables reduces cpu usage. -- 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-2053) Dev Guide: Syntax errors in SQL tips -> Tricks of the VALUES clause -> Multiple rows
Dev Guide: Syntax errors in SQL tips -> Tricks of the VALUES clause -> Multiple
rows
Key: DERBY-2053
URL: http://issues.apache.org/jira/browse/DERBY-2053
Project: Derby
Issue Type: Bug
Components: Documentation
Affects Versions: 10.2.1.6, 10.1.3.1, 10.3.0.0
Environment: N/A
Reporter: John H. Embretsen
Priority: Minor
Fix For: 10.2.2.0
In the "Derby Developer's Guide" manual, there is a page entitled "Multiple
rows", under section "SQL tips" and subsection "Tricks of the VALUES clause",
see
http://db.apache.org/derby/docs/dev/devguide/cdevtricks807337.html
for the current alpha/trunk version.
This page contains an SQL/IJ example with syntax errors:
-- send 5 rows at a time:
PREPARE p1 AS 'INSERT INTO ThreeColumnTable VALUES
(?,?,?), (?,?,?), (?,?,?), (?,?,?), (?,?,?)
EXECUTE p1 USING 'VALUES (''1st'',1,1,''2nd'',2,2''3rd'',
3,3,''4th'',4,4,''5th'',5,5)'
Errors are:
* The PREPARE command will fail because of a missing end quote (').
* The EXECUTE command will fail because of a missing comma, between ,2,2 and
"3rd".
* Since this is an IJ example (although that may not be immediately clear to
all readers; "ij> " should be added in front of each command), both commands
lack a semicolon (;) at the end.
--
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-2042) Provide documentation for new RENAME COLUMN statement
[ http://issues.apache.org/jira/browse/DERBY-2042?page=comments#action_12448072 ] Knut Anders Hatlen commented on DERBY-2042: --- Thanks Bryan, the changes look great! One last comment. I looked at how the page for CREATE INDEX defined the syntax. It doesn't mention schema name in the syntax description, but table-Name is a hyperlink to a page which defines table-Name as [ schemaName. ] SQL92Identifier. Also, I started wondering whether it is correct to use "new-Column-Name" in the syntax. Perhaps it is more semantics than syntax. I think we could write the syntax this way (with hyperlinks to the definitions of table-Name and Simple-column-Name): RENAME COLUMN table-Name.Simple-column-Name TO Simple-column-Name And a final nit: In the text that explains the examples, the identifiers "manager", "employee" and "supervisor" are written in plain text with no quotation marks, but "c1" and "t" are written in double quotes. Perhaps the DITA experts know a markup tag which could be used to consistently mark identifiers? > Provide documentation for new RENAME COLUMN statement > - > > Key: DERBY-2042 > URL: http://issues.apache.org/jira/browse/DERBY-2042 > Project: Derby > Issue Type: Improvement > Components: Documentation >Affects Versions: 10.3.0.0 >Reporter: Bryan Pendleton > Assigned To: Bryan Pendleton >Priority: Minor > Attachments: renameColumnDoc_v1.diff, renameColumnDoc_v2.diff, > rrefsqljrenamecolumnstatement.html, rrefsqljrenamecolumnstatement.html > > > DERBY-1490 proposes to add a new RENAME COLUMN statement. Assuming that such > a statement is added, we need to update the documentation to describe this > new statement. DERBY-1490 describes the behavior of the statement in detail; > this issue is just to track the documentation, which I intend to address > separately after the DERBY-1490 changes are committed. -- 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
