[jira] [Closed] (DERBY-5711) NullsTest doesn't call super.tearDown()
[
https://issues.apache.org/jira/browse/DERBY-5711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-5711.
-
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue fix info: (was: Patch Available)
Thanks, Kristian.
Committed revision 1330120.
NullsTest doesn't call super.tearDown()
---
Key: DERBY-5711
URL: https://issues.apache.org/jira/browse/DERBY-5711
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Fix For: 10.9.0.0
Attachments: d5711-1a.diff
NullsTest has the following tearDown() method:
public void tearDown() throws SQLException{
getConnection().setAutoCommit(true);
}
Since it doesn't call super.tearDown(), it doesn't release connections and
statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5710) BigDataTest.tearDown() doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5710. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Thanks, Kristian. Committed revision 1330121. BigDataTest.tearDown() doesn't call super.tearDown() Key: DERBY-5710 URL: https://issues.apache.org/jira/browse/DERBY-5710 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5710-1a.diff BigDataTest's tearDown() method doesn't call super.tearDown(), causing it to leave statements and connections open and not eligible for gc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5709) ResultSetFromPreparedStatementTest keeps references to non-default connections
[ https://issues.apache.org/jira/browse/DERBY-5709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5709. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Thanks, Kristian. Committed revision 1330127. ResultSetFromPreparedStatementTest keeps references to non-default connections -- Key: DERBY-5709 URL: https://issues.apache.org/jira/browse/DERBY-5709 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5709-1a.diff ResultSetFromPreparedStatementTest keeps references to non-default connections in the fields c2 and c3. c2 is closed and nulled out in tearDown(). c3 is only closed. It should be nulled out too in order to allow gc of resources after test completion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5715) InbetweenTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5715: -- Attachment: d5715-1a.diff The attached patch removes the instance variables from InbetweenTest and makes it use local variables instead. This makes the objects eligible for gc once the test has completed. InbetweenTest holds on to resources after completion Key: DERBY-5715 URL: https://issues.apache.org/jira/browse/DERBY-5715 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5715-1a.diff InbetweenTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5716) TimestampArithTest keeps references to statements after completion
[ https://issues.apache.org/jira/browse/DERBY-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5716: -- Issue fix info: Patch Available TimestampArithTest keeps references to statements after completion -- Key: DERBY-5716 URL: https://issues.apache.org/jira/browse/DERBY-5716 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5716-1a.diff TimestampArithTest keeps references to statements in static fields, but never closes them or clears the fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5716) TimestampArithTest keeps references to statements after completion
[ https://issues.apache.org/jira/browse/DERBY-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5716: -- Attachment: d5716-1a.diff Attaching a patch that makes two changes to the test: 1) It adds a tearDown() method that closes the statements and clears the references to them. 2) This is a data-driven test. However, the test inputs are stored in non-static variables, so they are duplicated in memory as many times as there are test cases. The patch makes the variables that hold the test input static to reduce the memory footprint of the test. TimestampArithTest keeps references to statements after completion -- Key: DERBY-5716 URL: https://issues.apache.org/jira/browse/DERBY-5716 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5716-1a.diff TimestampArithTest keeps references to statements in static fields, but never closes them or clears the fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5715) InbetweenTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5715: -- Issue fix info: Patch Available InbetweenTest holds on to resources after completion Key: DERBY-5715 URL: https://issues.apache.org/jira/browse/DERBY-5715 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5715-1a.diff InbetweenTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5717) TableFunctionTest keeps reference to connection after completion
[ https://issues.apache.org/jira/browse/DERBY-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5717: -- Attachment: d5717-1a.diff The attached patch clears the _databaseMetaData field in tearDown(). TableFunctionTest keeps reference to connection after completion Key: DERBY-5717 URL: https://issues.apache.org/jira/browse/DERBY-5717 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Attachments: d5717-1a.diff The test cases in TableFunctionTest store a DatabaseMetaData instance in an instance variable. The DatabaseMetaData instance references the default connection, and the connection can therefore not be gc'ed after the test has completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5717) TableFunctionTest keeps reference to connection after completion
[ https://issues.apache.org/jira/browse/DERBY-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5717: -- Issue fix info: Patch Available Assignee: Knut Anders Hatlen TableFunctionTest keeps reference to connection after completion Key: DERBY-5717 URL: https://issues.apache.org/jira/browse/DERBY-5717 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5717-1a.diff The test cases in TableFunctionTest store a DatabaseMetaData instance in an instance variable. The DatabaseMetaData instance references the default connection, and the connection can therefore not be gc'ed after the test has completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5717) TableFunctionTest keeps reference to connection after completion
[ https://issues.apache.org/jira/browse/DERBY-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261412#comment-13261412 ] Kristian Waagan commented on DERBY-5717: +1 TableFunctionTest keeps reference to connection after completion Key: DERBY-5717 URL: https://issues.apache.org/jira/browse/DERBY-5717 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5717-1a.diff The test cases in TableFunctionTest store a DatabaseMetaData instance in an instance variable. The DatabaseMetaData instance references the default connection, and the connection can therefore not be gc'ed after the test has completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5717) TableFunctionTest keeps reference to connection after completion
[ https://issues.apache.org/jira/browse/DERBY-5717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5717. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Thanks, Kristian. Committed revision 1330194. TableFunctionTest keeps reference to connection after completion Key: DERBY-5717 URL: https://issues.apache.org/jira/browse/DERBY-5717 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5717-1a.diff The test cases in TableFunctionTest store a DatabaseMetaData instance in an instance variable. The DatabaseMetaData instance references the default connection, and the connection can therefore not be gc'ed after the test has completed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5704) Various cleanups in CoalesceTest
[
https://issues.apache.org/jira/browse/DERBY-5704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-5704.
-
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue fix info: (was: Patch Available)
Committed revision 1330195.
Various cleanups in CoalesceTest
Key: DERBY-5704
URL: https://issues.apache.org/jira/browse/DERBY-5704
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
Fix For: 10.9.0.0
Attachments: d5704-1a.diff
I noticed a couple of things that could be cleaned up in CoalesceTest:
- It keeps statements in instance variables. These are closed in tearDown(),
but not nulled out, so they are not gc'ed when the test completes.
- It has much code that follows the pattern
try {
s.execute(...);
} catch (SQLException sqle) {
assertSQLState(state, sqle);
}
which means it won't report a failure if the execution of the statement
succeeds unexpectedly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5712) CheckConstraintTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5712. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330199. CheckConstraintTest holds on to resources after completion -- Key: DERBY-5712 URL: https://issues.apache.org/jira/browse/DERBY-5712 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5712-1a.diff CheckConstraintTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5705) Authorization decorators don't null out connections when done
[ https://issues.apache.org/jira/browse/DERBY-5705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5705. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330196. Authorization decorators don't null out connections when done - Key: DERBY-5705 URL: https://issues.apache.org/jira/browse/DERBY-5705 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5705-1a.diff Some decorators used to test authorization don't close and null out references to Connection objects when they have completed. Since these tests often create/boot single-use databases, and the Connection objects have references to the database instance and, directly or indirectly, many of its modules, this prevents much garbage from being removed from the heap after the tests have completed and shut down their single-use databases. We should close the default connection and clear the reference to it when tearing down these decorators, so the space is released for subsequent tests to use. This problem affects decorators returned by the following methods: DatabasePropertyTestSetup.builtinAuthenticationNoTeardown() TestConfiguration.sqlAuthorizationDecorator() TestConfiguration.sqlAuthorizationDecoratorSingleUse() These methods return modified versions of DatabasePropertyTestSetup where the tearDown() method is a no-op. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5708) simpleThread test doesn't release connection
[ https://issues.apache.org/jira/browse/DERBY-5708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5708. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330197. simpleThread test doesn't release connection Key: DERBY-5708 URL: https://issues.apache.org/jira/browse/DERBY-5708 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5708-1a.diff The simpleThread test, which is run by LangHarnessJavaTest, stores its connection in a static field. It doesn't close the connection, or clear the static field, before returning. So the connection is left open for the rest of the test run (potentially for the entire duration of suites.All). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5713) AlterTableTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5713. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330200. AlterTableTest holds on to resources after completion - Key: DERBY-5713 URL: https://issues.apache.org/jira/browse/DERBY-5713 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5713-1a.diff AlterTableTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5714) ColumnDefaultsTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5714. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330201. ColumnDefaultsTest holds on to resources after completion - Key: DERBY-5714 URL: https://issues.apache.org/jira/browse/DERBY-5714 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5714-1a.diff ColumnDefaultsTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5718) UniqueConstraintSetNullTest calls super.tearDown() too early
[ https://issues.apache.org/jira/browse/DERBY-5718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5718. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330202. UniqueConstraintSetNullTest calls super.tearDown() too early Key: DERBY-5718 URL: https://issues.apache.org/jira/browse/DERBY-5718 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5718-1a.diff UniqueConstraintSetNullTest calls super.tearDown() first in its tearDown() method. After that, it opens a new connection and does some more cleanup. This connection is not closed or nulled out. If super.tearDown() had been called last, it would have been cleaned up correctly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5719) UniqueConstraintMultiThreadedTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5719. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330203. UniqueConstraintMultiThreadedTest doesn't call super.tearDown() --- Key: DERBY-5719 URL: https://issues.apache.org/jira/browse/DERBY-5719 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5719-1a.diff UniqueConstraintMultiThreadedTest has a tearDown() method that doesn't call super.tearDown(). It also keeps a DataSource in an instance variable and doesn't appear to null out the reference to it on completion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5720) UngroupedAggregatesNegativeTest doesn't call super.tearDown()
[
https://issues.apache.org/jira/browse/DERBY-5720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-5720.
-
Resolution: Fixed
Fix Version/s: 10.9.0.0
Issue fix info: (was: Patch Available)
Committed revision 1330204.
UngroupedAggregatesNegativeTest doesn't call super.tearDown()
-
Key: DERBY-5720
URL: https://issues.apache.org/jira/browse/DERBY-5720
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Fix For: 10.9.0.0
Attachments: d5720-1a.diff
public void tearDown() throws SQLException {
dropTable(t1);
dropTable(t2);
}
Should call super.tearDown() to close and release connection and statements.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5715) InbetweenTest holds on to resources after completion
[ https://issues.apache.org/jira/browse/DERBY-5715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5715. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330206. InbetweenTest holds on to resources after completion Key: DERBY-5715 URL: https://issues.apache.org/jira/browse/DERBY-5715 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5715-1a.diff InbetweenTest keeps connections, statements and result sets in instance variables, but never clears the variables, so they are kept forever. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (DERBY-5716) TimestampArithTest keeps references to statements after completion
[ https://issues.apache.org/jira/browse/DERBY-5716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen closed DERBY-5716. - Resolution: Fixed Fix Version/s: 10.9.0.0 Issue fix info: (was: Patch Available) Committed revision 1330207. TimestampArithTest keeps references to statements after completion -- Key: DERBY-5716 URL: https://issues.apache.org/jira/browse/DERBY-5716 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Fix For: 10.9.0.0 Attachments: d5716-1a.diff TimestampArithTest keeps references to statements in static fields, but never closes them or clears the fields. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5721) ParameterMappingTest lacks call to super.tearDown()
Knut Anders Hatlen created DERBY-5721: - Summary: ParameterMappingTest lacks call to super.tearDown() Key: DERBY-5721 URL: https://issues.apache.org/jira/browse/DERBY-5721 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen ParameterMappingTest.tearDown() should call super.tearDown() to release connections/statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5722) InternationalConnectTest forgets to call super.tearDown()
Knut Anders Hatlen created DERBY-5722: - Summary: InternationalConnectTest forgets to call super.tearDown() Key: DERBY-5722 URL: https://issues.apache.org/jira/browse/DERBY-5722 Project: Derby Issue Type: Bug Reporter: Knut Anders Hatlen Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5723) LongColumnTest doesn't call super.tearDown()
Knut Anders Hatlen created DERBY-5723: - Summary: LongColumnTest doesn't call super.tearDown() Key: DERBY-5723 URL: https://issues.apache.org/jira/browse/DERBY-5723 Project: Derby Issue Type: Bug Reporter: Knut Anders Hatlen Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5724) EncryptionKeyTest sometimes keep reference to connection
Knut Anders Hatlen created DERBY-5724:
-
Summary: EncryptionKeyTest sometimes keep reference to connection
Key: DERBY-5724
URL: https://issues.apache.org/jira/browse/DERBY-5724
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
EncryptionKeyTest has this code to clean up the connection:
if (con != null !con.isClosed()) {
con.rollback();
con.close();
con = null;
}
If the connection is already closed, it won't null out the reference. It should
set con to null unconditionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5723) LongColumnTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5723: -- Component/s: Test Affects Version/s: 10.9.0.0 LongColumnTest doesn't call super.tearDown() Key: DERBY-5723 URL: https://issues.apache.org/jira/browse/DERBY-5723 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5722) InternationalConnectTest forgets to call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5722: -- Component/s: Test Affects Version/s: 10.9.0.0 InternationalConnectTest forgets to call super.tearDown() - Key: DERBY-5722 URL: https://issues.apache.org/jira/browse/DERBY-5722 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5725) ErrorStreamTest doesn't call super.tearDown()
Knut Anders Hatlen created DERBY-5725: - Summary: ErrorStreamTest doesn't call super.tearDown() Key: DERBY-5725 URL: https://issues.apache.org/jira/browse/DERBY-5725 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5726) Make it more difficult to forget calling super.tearDown() from BaseJDBCTestCase's subclasses
Knut Anders Hatlen created DERBY-5726:
-
Summary: Make it more difficult to forget calling super.tearDown()
from BaseJDBCTestCase's subclasses
Key: DERBY-5726
URL: https://issues.apache.org/jira/browse/DERBY-5726
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
Many of the classes that extend BaseJDBCTestCase and override the tearDown()
method, forget to call super.tearDown(), and thereby prevent resources from
being freed after completion. We should add a mechanism that enforces the
correct behaviour.
If we were starting from scratch, we might have made
BaseJDBCTestCase.tearDown() final and added a new overridable method that was
called from BaseJDBCTestCase.tearDown() before it freed the statements and
connections. Then there would be no way to prevent BaseJDBCTestCase.tearDown()
from running in the subclasses. That would however require us to change all
existing overrides of BaseJDBCTestCase.tearDown() (current count: 131), which
would be a chunk of work.
I'd rather suggest that we add an override of runBare() in BaseJDBCTestCase
that asserts that the connection has been cleared out when a test case has
completed successfully. Something like this:
public void runBare() throws Throwable {
super.runBare();
// It's quite common to forget to call super.tearDown() when
// overriding tearDown() in sub-classes.
assertNull(
Connection should be null by now. +
Missing call to super.tearDown()?, conn);
}
Then it would still be possible to forget to call super.tearDown(), but it
would be discovered when trying to run the test.
Adding the above method to BaseJDBCTestCase and running
InternationalConnectTest gave this result:
.F.FF
Time: 5,748
There were 3 failures:
1)
testDriverManagerConnect(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
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)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
2)
testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
(...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5726) Make it more difficult to forget calling super.tearDown() from BaseJDBCTestCase's subclasses
[
https://issues.apache.org/jira/browse/DERBY-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261603#comment-13261603
]
Rick Hillegas commented on DERBY-5726:
--
Hi Knut,
That sounds like a good idea. Maybe you can apply your first suggestion to the
runBare() solution, making runBare() final and having it call an overridable
method. Shouldn't be too messy. I only see overrides of runBare() in a handful
of classes.
Thanks,
-Rick
Make it more difficult to forget calling super.tearDown() from
BaseJDBCTestCase's subclasses
Key: DERBY-5726
URL: https://issues.apache.org/jira/browse/DERBY-5726
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
Many of the classes that extend BaseJDBCTestCase and override the tearDown()
method, forget to call super.tearDown(), and thereby prevent resources from
being freed after completion. We should add a mechanism that enforces the
correct behaviour.
If we were starting from scratch, we might have made
BaseJDBCTestCase.tearDown() final and added a new overridable method that was
called from BaseJDBCTestCase.tearDown() before it freed the statements and
connections. Then there would be no way to prevent
BaseJDBCTestCase.tearDown() from running in the subclasses. That would
however require us to change all existing overrides of
BaseJDBCTestCase.tearDown() (current count: 131), which would be a chunk of
work.
I'd rather suggest that we add an override of runBare() in BaseJDBCTestCase
that asserts that the connection has been cleared out when a test case has
completed successfully. Something like this:
public void runBare() throws Throwable {
super.runBare();
// It's quite common to forget to call super.tearDown() when
// overriding tearDown() in sub-classes.
assertNull(
Connection should be null by now. +
Missing call to super.tearDown()?, conn);
}
Then it would still be possible to forget to call super.tearDown(), but it
would be discovered when trying to run the test.
Adding the above method to BaseJDBCTestCase and running
InternationalConnectTest gave this result:
.F.FF
Time: 5,748
There were 3 failures:
1)
testDriverManagerConnect(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
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)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
2)
testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
(...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DERBY-5722) InternationalConnectTest forgets to call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen reassigned DERBY-5722: - Assignee: Knut Anders Hatlen InternationalConnectTest forgets to call super.tearDown() - Key: DERBY-5722 URL: https://issues.apache.org/jira/browse/DERBY-5722 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5722) InternationalConnectTest forgets to call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5722: -- Attachment: d5722-1a.diff The attached patch makes the following changes to InternationalConnectTest to make it free resources on completion: - Call super.tearDown() from tearDown() - Close XAConnections and PooledConnections - Clear reference to ArrayList in tearDown() to allow it to be gc'ed InternationalConnectTest forgets to call super.tearDown() - Key: DERBY-5722 URL: https://issues.apache.org/jira/browse/DERBY-5722 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5722-1a.diff Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (DERBY-5721) ParameterMappingTest lacks call to super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen reassigned DERBY-5721: - Assignee: Knut Anders Hatlen ParameterMappingTest lacks call to super.tearDown() --- Key: DERBY-5721 URL: https://issues.apache.org/jira/browse/DERBY-5721 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen ParameterMappingTest.tearDown() should call super.tearDown() to release connections/statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5721) ParameterMappingTest lacks call to super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5721: -- Issue fix info: Patch Available ParameterMappingTest lacks call to super.tearDown() --- Key: DERBY-5721 URL: https://issues.apache.org/jira/browse/DERBY-5721 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5721-1a.diff ParameterMappingTest.tearDown() should call super.tearDown() to release connections/statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5722) InternationalConnectTest forgets to call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5722: -- Issue fix info: Patch Available InternationalConnectTest forgets to call super.tearDown() - Key: DERBY-5722 URL: https://issues.apache.org/jira/browse/DERBY-5722 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5722-1a.diff Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5721) ParameterMappingTest lacks call to super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5721: -- Attachment: d5721-1a.diff Attaching a patch that simplifies tearDown() by using helper methods, and adds the missing call to super.tearDown(). ParameterMappingTest lacks call to super.tearDown() --- Key: DERBY-5721 URL: https://issues.apache.org/jira/browse/DERBY-5721 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5721-1a.diff ParameterMappingTest.tearDown() should call super.tearDown() to release connections/statements. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5727) Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM
Kristian Waagan created DERBY-5727: -- Summary: Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM Key: DERBY-5727 URL: https://issues.apache.org/jira/browse/DERBY-5727 Project: Derby Issue Type: Task Components: Build tools Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan As per Apache infra's request Maven artifacts should be deployed to repository.apache.org. Derby is currently deploying to people.apache.org, for which Maven deployment will be disabled in Jan 2013. Additionally, the Derby POMs should refer to the ASF top-level POM as the parent. There are several advantages to doing this, see [1] for details. [1] http://www.apache.org/dev/publishing-maven-artifacts.html#inherit-parent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5723) LongColumnTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5723: -- Attachment: d5723-1a.diff The attached patch adds the missing call. LongColumnTest doesn't call super.tearDown() Key: DERBY-5723 URL: https://issues.apache.org/jira/browse/DERBY-5723 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Attachments: d5723-1a.diff Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5723) LongColumnTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5723: -- Issue fix info: Patch Available Assignee: Knut Anders Hatlen LongColumnTest doesn't call super.tearDown() Key: DERBY-5723 URL: https://issues.apache.org/jira/browse/DERBY-5723 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5723-1a.diff Its tearDown() method should call super.tearDown() to free resources. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5724) EncryptionKeyTest sometimes keep reference to connection
[
https://issues.apache.org/jira/browse/DERBY-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5724:
--
Attachment: d5724-1a.diff
Attaching a patch that makes tearDown() null out the connection unconditionally.
EncryptionKeyTest sometimes keep reference to connection
Key: DERBY-5724
URL: https://issues.apache.org/jira/browse/DERBY-5724
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Attachments: d5724-1a.diff
EncryptionKeyTest has this code to clean up the connection:
if (con != null !con.isClosed()) {
con.rollback();
con.close();
con = null;
}
If the connection is already closed, it won't null out the reference. It
should set con to null unconditionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5724) EncryptionKeyTest sometimes keeps reference to connection
[
https://issues.apache.org/jira/browse/DERBY-5724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5724:
--
Issue fix info: Patch Available
Assignee: Knut Anders Hatlen
Summary: EncryptionKeyTest sometimes keeps reference to connection
(was: EncryptionKeyTest sometimes keep reference to connection)
EncryptionKeyTest sometimes keeps reference to connection
-
Key: DERBY-5724
URL: https://issues.apache.org/jira/browse/DERBY-5724
Project: Derby
Issue Type: Bug
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Attachments: d5724-1a.diff
EncryptionKeyTest has this code to clean up the connection:
if (con != null !con.isClosed()) {
con.rollback();
con.close();
con = null;
}
If the connection is already closed, it won't null out the reference. It
should set con to null unconditionally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5727) Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM
[ https://issues.apache.org/jira/browse/DERBY-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-5727: --- Issue fix info: Patch Available Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM - Key: DERBY-5727 URL: https://issues.apache.org/jira/browse/DERBY-5727 Project: Derby Issue Type: Task Components: Build tools Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Attachments: derby-5727-1a-inherit_asf_pom.diff As per Apache infra's request Maven artifacts should be deployed to repository.apache.org. Derby is currently deploying to people.apache.org, for which Maven deployment will be disabled in Jan 2013. Additionally, the Derby POMs should refer to the ASF top-level POM as the parent. There are several advantages to doing this, see [1] for details. [1] http://www.apache.org/dev/publishing-maven-artifacts.html#inherit-parent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5727) Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM
[ https://issues.apache.org/jira/browse/DERBY-5727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kristian Waagan updated DERBY-5727: --- Attachment: derby-5727-1a-inherit_asf_pom.diff Attaching patch 1a, which makes the derby-project POM inherit the ASF top-level POM. This makes Maven deploy to repository.apache.org. In addition I've updated the readme file. I've tested this once on Solaris 11 with Maven 3. It would be nice if PMC members on different platforms could test it too. You can safely test it with a 10.9.0.0_alpha build (trunk), just don't release the temporary repository in Nexus :) Nexus lives at repository.apache.org, log in with your LDAP credentials. Patch ready for review. Update POMs to deploy Maven artifacts to repository.apache.org and use ASF parent POM - Key: DERBY-5727 URL: https://issues.apache.org/jira/browse/DERBY-5727 Project: Derby Issue Type: Task Components: Build tools Affects Versions: 10.9.0.0 Reporter: Kristian Waagan Assignee: Kristian Waagan Attachments: derby-5727-1a-inherit_asf_pom.diff As per Apache infra's request Maven artifacts should be deployed to repository.apache.org. Derby is currently deploying to people.apache.org, for which Maven deployment will be disabled in Jan 2013. Additionally, the Derby POMs should refer to the ASF top-level POM as the parent. There are several advantages to doing this, see [1] for details. [1] http://www.apache.org/dev/publishing-maven-artifacts.html#inherit-parent -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5725) ErrorStreamTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5725: -- Attachment: d5725-1a.diff The attached patch adds the missing call. ErrorStreamTest doesn't call super.tearDown() - Key: DERBY-5725 URL: https://issues.apache.org/jira/browse/DERBY-5725 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Attachments: d5725-1a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5725) ErrorStreamTest doesn't call super.tearDown()
[ https://issues.apache.org/jira/browse/DERBY-5725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Knut Anders Hatlen updated DERBY-5725: -- Issue fix info: Patch Available Assignee: Knut Anders Hatlen ErrorStreamTest doesn't call super.tearDown() - Key: DERBY-5725 URL: https://issues.apache.org/jira/browse/DERBY-5725 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen Assignee: Knut Anders Hatlen Attachments: d5725-1a.diff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Regression Test Report - Daily 1329813 - Sun DBTG
[Auto-generated mail] *Daily* 1329813/2012-04-24 18:00:08 MEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.7* lin 01558315583 0 .% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 0 .% derbyall 022 0 .% compatibility 022 0 .% demoSuite sol NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite sol32 NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite vista-64 01557415574 0 .% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 0 .% derbyall NA NA NANA compatibility 022 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/Limited/testSummary-1329813.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/FailReports/1329813_bySig.html *Jvm: 1.6* lin 01547815478 0 1603.32% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 037.75% derbyall 022 0 112.40% compatibility 022 0 .% demoSuite sles 01547815478 0 1028.19% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 034.72% derbyall 022 098.02% compatibility 022 0 .% demoSuite sol NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite sol32 NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite solN+1 01546615466 0 228.43% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 045.48% derbyall 022 076.58% compatibility 022 0 .% demoSuite sparc NA NA NANA suitesAll NA NA NANA jdbcapiAutoLoad NA NA NANA JDBCDriversAll NA NA NANA JDBCDriversClient NA NA NANA JDBCDriversEmbedded NA NA NANA derbyall NA NA NANA compatibility NA NA NANA demoSuite vista 01546715467 0 199.13% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0166166 044.79% derbyall NA NA NANA compatibility 02
Maven debug and source artifacts for Derby
Hi, A few JIRAs have been logged where users are requesting that the Derby community provide debug artifacts for Maven (links at the end): o DERBY-5668: Derby does not publish source artifacts to Maven Central o DERBY-5543: include debug info in derby builds uploaded to maven o DERBY-3910: debug artifacts should be available in maven repositories Regarding the source artifacts, I think we should just do it! Does anyone see a reason why we don't want to do it? The debug artifacts requires a little more consideration. There are two requests at play here: a) include line numbers b) include the extra checks guarded by the SanityManager blocks (what's called a sane build) I think many of the users would want to use artifacts (a). In fact I'd say they should probably be the default. I imagine artifacts (b) to be used during development and when you debug a problem. What we are currently proving is more along the lines of (c): c) reduced disk-footprint JARs for small devices (a) and (c) are suitable for production, (b) isn't because of the performance degradation caused by the extra sanity checks. A recent build of trunk shows the following increases in size when including line numbers [1]: o derby.jar: 2.6 MB - 3.5 MB o derbyclient.jar: 523 KB - 686 KB o derbynet.jar: 237 KB - 302 KB Not compiling away the extra checks only adds a little more. The growth is most significant for derby.jar, where it ends up at 3.7 MB. They way I see it, adding line numbers has the following potential benefits: o make it easier for users to debug/investigate a problem where they get a stack trace o make it easier for the Derby community to start debugging a problem when they have a stack trace The only downside I see is the increase in size. This probably isn't a big deal for most users, but I expect there will be some users that want to keep things as small as possible. As a note to this, there has been some speculation (?) that the increased size may slow down class loading. Again I assume this is a concern to only a subset of our users. Together with source artifacts, I believe adding debug information will make it easier for people using Maven as their build tool to get involved with Derby. I think providing these artifacts can benefit both these users and the Derby community. I can't see how providing these artifacts would hurt. What do others think? Links to the issues mentioned: https://issues.apache.org/jira/browse/DERBY-5668 https://issues.apache.org/jira/browse/DERBY-5543 https://issues.apache.org/jira/browse/DERBY-3910 Regards, -- Kristian [1] We're only specifying debug=true, which I assume has the same effect as debug=on. This again I'm assuming causes -g to be passed to the compiler, since we're not specifying debuglevel, and -g means all debug information (-g:lines,vars,source).
[jira] [Commented] (DERBY-5667) testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet
[ https://issues.apache.org/jira/browse/DERBY-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261827#comment-13261827 ] Mike Matrigali commented on DERBY-5667: --- the second patch looks good to me. testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet --- Key: DERBY-5667 URL: https://issues.apache.org/jira/browse/DERBY-5667 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.2.3 Reporter: Mike Matrigali Attachments: DERBY-5667.diff, DERBY-5667_2.diff one failure and 2 errors which I would guess are because of the failure. Failed against 10.8 branch, ibm15, windows, build 1302046 There were 2 errors: 1) testSerializable(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(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.executeUpdate(Unknown Source) at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185) at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testSerializable(UpdateLocksTest.java:154) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) 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) 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) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown Source) at org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown Source) at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 36 more 2) testReadUncommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(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.executeUpdate(Unknown Source) at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185) at
[jira] [Commented] (DERBY-5726) Make it more difficult to forget calling super.tearDown() from BaseJDBCTestCase's subclasses
[
https://issues.apache.org/jira/browse/DERBY-5726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261847#comment-13261847
]
Knut Anders Hatlen commented on DERBY-5726:
---
There were no failures in suites.All when running with the above mentioned
runBare() method in BaseJDBCTestCase, as well as the uncommitted patches
attached to DERBY-5721, DERBY-5722, DERBY-5723 and DERBY-5725. So at least it
looks like we've smoked out most of these problems now.
I'll see if I can modify the patch as Rick suggested. There is actually just
one override of BaseJDBCTestCase.runBare(), and that's in JDBCPerfTestCase. The
other runBare() overrides are in direct subclasses of BaseTestCase, which
doesn't have any connections or statements to close.
Make it more difficult to forget calling super.tearDown() from
BaseJDBCTestCase's subclasses
Key: DERBY-5726
URL: https://issues.apache.org/jira/browse/DERBY-5726
Project: Derby
Issue Type: Improvement
Components: Test
Affects Versions: 10.9.0.0
Reporter: Knut Anders Hatlen
Assignee: Knut Anders Hatlen
Priority: Minor
Many of the classes that extend BaseJDBCTestCase and override the tearDown()
method, forget to call super.tearDown(), and thereby prevent resources from
being freed after completion. We should add a mechanism that enforces the
correct behaviour.
If we were starting from scratch, we might have made
BaseJDBCTestCase.tearDown() final and added a new overridable method that was
called from BaseJDBCTestCase.tearDown() before it freed the statements and
connections. Then there would be no way to prevent
BaseJDBCTestCase.tearDown() from running in the subclasses. That would
however require us to change all existing overrides of
BaseJDBCTestCase.tearDown() (current count: 131), which would be a chunk of
work.
I'd rather suggest that we add an override of runBare() in BaseJDBCTestCase
that asserts that the connection has been cleared out when a test case has
completed successfully. Something like this:
public void runBare() throws Throwable {
super.runBare();
// It's quite common to forget to call super.tearDown() when
// overriding tearDown() in sub-classes.
assertNull(
Connection should be null by now. +
Missing call to super.tearDown()?, conn);
}
Then it would still be possible to forget to call super.tearDown(), but it
would be discovered when trying to run the test.
Adding the above method to BaseJDBCTestCase and running
InternationalConnectTest gave this result:
.F.FF
Time: 5,748
There were 3 failures:
1)
testDriverManagerConnect(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
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)
at
org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
2)
testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)junit.framework.AssertionFailedError:
Connection should be null by now. Missing call to super.tearDown()?
at
org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:431)
(...)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-4115) Provide a way to drop statistics information
[ https://issues.apache.org/jira/browse/DERBY-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mamta A. Satoor updated DERBY-4115: --- Attachment: DERBY4115_patch3_diff.txt I am attaching another patch(DERBY4115_patch3_diff) which is similar to patch 2 with the addition of basic upgrade test for the new procedure. This test ensures that drop statistics procedure is available only after hard upgrade. Provide a way to drop statistics information Key: DERBY-4115 URL: https://issues.apache.org/jira/browse/DERBY-4115 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.6.1.0 Reporter: Kathey Marsden Assignee: Mamta A. Satoor Attachments: DERBY4115_patch1_diff.txt, DERBY4115_patch2_diff.txt, DERBY4115_patch3_diff.txt Now that DERBY-269 has been resolved, users can update statistics, but once they do, they are committed to using and maintaining the statistics, even if it doesn't improve performance or they have difficulty maintaining the statistics on a regular basis. It would be good to have a way to drop statistics information so that users could revert to the prior behavior if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-4115) Provide a way to drop statistics information
[ https://issues.apache.org/jira/browse/DERBY-4115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261884#comment-13261884 ] Mamta A. Satoor commented on DERBY-4115: As the next step, I am looking at actually implementing the routine now that the ground work is done. I think the implementation should be similar to update statistics, ie allow the code to go through ALTER TABLE where permission/privilege checking, table/schema/index name validations happen automatically and we can implement the routine through ALTER TABLE. This will require changing ALTER TABLE syntax(same as we did for update statistics) but it will be an internal syntax and won't be available to an end user directly. Provide a way to drop statistics information Key: DERBY-4115 URL: https://issues.apache.org/jira/browse/DERBY-4115 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.6.1.0 Reporter: Kathey Marsden Assignee: Mamta A. Satoor Attachments: DERBY4115_patch1_diff.txt, DERBY4115_patch2_diff.txt, DERBY4115_patch3_diff.txt Now that DERBY-269 has been resolved, users can update statistics, but once they do, they are committed to using and maintaining the statistics, even if it doesn't improve performance or they have difficulty maintaining the statistics on a regular basis. It would be good to have a way to drop statistics information so that users could revert to the prior behavior if needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5679) Rolling back a transaction leads to an inconsistent state
[ https://issues.apache.org/jira/browse/DERBY-5679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261946#comment-13261946 ] Mike Matrigali commented on DERBY-5679: --- I think the approach of getting update to log nulls in this case is a good one. Store is going to be broken if non-existent columns are anywhere other than at the end of the row. Changing non-existent columns to null valued columns at update time seems like a good approach. Is the code you are changing happening because the user update is updating column N with a value, column N-1 and N were added because of add column and neither has ever had a real value. And this trip through log column is dealing with column N-1. I think it might be cleaner if you just add another if/then/else just for COLUMN_NULL at line 6306, rather than code the case of a real column and a nonexistent column in same case. I think sColumn is null for your case in this and found it confusing, seems like the code works by accident not referencing the null pointer, so someone later could easily use it thinking it was valid. The code for COLUMN_NULL is much simpler as it just knows it is creating a NULL value out of the ether. nits: o could you make the code be 80 column o I think a different name might be better, maybe COLUMN_CREATENULL. I kept seeing the COLUMN_NULL name and thinking it was an existing null column, which is a different code path. o could you add comments to logColumn to say what the new option is doing. o a good case to add but does not need to hold up your checkin would be both regular row and long row case. Something like add 100 columns, update 50th column, check you can retrieve all 100, abort check you can retrieve all as expected. Another row do 50th update and then 99th update The long row case comes when you make all this work happen on second page vs first, so for 2k pages something like following: create table with real columns to fill most of a page. with just ddl you can add columns of char(250) that will guarantee 250 bytes for any insert, or you can use clob/blob and make sure you add almost pagesize bytes. Then use alter to add columns. interesting cases would be some nonexistent columns on first page and then an update of one that will end up on second page or more. Rolling back a transaction leads to an inconsistent state - Key: DERBY-5679 URL: https://issues.apache.org/jira/browse/DERBY-5679 Project: Derby Issue Type: Bug Components: Store Affects Versions: 10.6.2.1, 10.8.2.2 Environment: sysinfo -- Java Information -- Java Version:1.6.0_26 Java Vendor: Sun Microsystems Inc. Java home: C:\Program Files (x86)\Java\jre6 Java classpath: .;C:\Program Files (x86)\Java\jre7\lib\ext\QTJava.zip;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derby.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbynet.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbyclient.jar;C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin\../lib/derbytools.jar OS name: Windows 7 OS architecture: x86 OS version: 6.1 Java user name: bmason Java user home: C:\Users\BMASON Java user dir: C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\bin java.specification.name: Java Platform API Specification java.specification.version: 1.6 java.runtime.version: 1.6.0_26-b03 - Derby Information JRE - JDBC: Java SE 6 - JDBC 4.0 [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derby.jar] 10.8.2.2 - (1181258) [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbytools.jar] 10.8.2.2 - (1181258) [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbynet.jar] 10.8.2.2 - (1181258) [C:\Users\BMASON\Sandbox\libs\db-derby-10.8.2.2-bin\lib\derbyclient.jar] 10.8.2.2 - (1181258) -- - Locale Information - Current Locale : [English/New Zealand [en_NZ]] Found support for locale: [cs] version: 10.8.2.2 - (1181258) Found support for locale: [de_DE] version: 10.8.2.2 - (1181258) Found support for locale: [es] version: 10.8.2.2 - (1181258) Found support for locale: [fr] version: 10.8.2.2 - (1181258) Found support for locale: [hu] version: 10.8.2.2 - (1181258) Found support for locale: [it] version: 10.8.2.2 - (1181258) Found support for locale: [ja_JP] version: 10.8.2.2 - (1181258) Found support for locale: [ko_KR] version: 10.8.2.2 - (1181258) Found support for locale: [pl] version: 10.8.2.2 - (1181258) Found support for
[jira] [Commented] (DERBY-5696) Documentation on LOBs needs some fixes
[ https://issues.apache.org/jira/browse/DERBY-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13261952#comment-13261952 ] Kim Haase commented on DERBY-5696: -- Thanks very much for that explanation, Kristian. I'll work with it and file a patch that I hope will put things correctly. Documentation on LOBs needs some fixes -- Key: DERBY-5696 URL: https://issues.apache.org/jira/browse/DERBY-5696 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.8.2.2 Reporter: Kim Haase Assignee: Kim Haase DERBY-5489 points out some issues with multiple getXXX calls on LOBs that are not fully documented. The information should probably be added to Notes on mapping of java.sql.Blob and java.sql.Clob interfaces. In addition, the topic Mapping of java.sql.Blob and java.sql.Clob interfaces has a typo and could probably use some additional information as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DERBY-5667) testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet
[ https://issues.apache.org/jira/browse/DERBY-5667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Myrna van Lunteren resolved DERBY-5667. --- Resolution: Fixed Fix Version/s: 10.9.0.0 10.8.2.3 Assignee: Myrna van Lunteren I applied the changes as per patch _2.diff to trunk with revision 1330482 and merged 1330066 and 1330482 to 10.8 with revision 1330489. I'm resolving this issue. It's possible the test will fail again because of activity resulting from updates, if it does, we can repeat the solution for that. testReadCommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet --- Key: DERBY-5667 URL: https://issues.apache.org/jira/browse/DERBY-5667 Project: Derby Issue Type: Bug Components: Test Affects Versions: 10.8.2.3 Reporter: Mike Matrigali Assignee: Myrna van Lunteren Fix For: 10.8.2.3, 10.9.0.0 Attachments: DERBY-5667.diff, DERBY-5667_2.diff one failure and 2 errors which I would guess are because of the failure. Failed against 10.8 branch, ibm15, windows, build 1302046 There were 2 errors: 1) testSerializable(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(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.executeUpdate(Unknown Source) at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185) at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testSerializable(UpdateLocksTest.java:154) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113) 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) 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) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown Source) at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown Source) at org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown Source) at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) ... 36 more 2) testReadUncommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException: Table/View 'A' already exists in Schema 'APP'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source) at
[jira] [Updated] (DERBY-5696) Documentation on LOBs needs some fixes
[ https://issues.apache.org/jira/browse/DERBY-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-5696: - Attachment: rrefjdbc96386.html DERBY-5696.diff I think that we can get away with adding just one sentence to the topic, placed reasonably prominently (in a paragraph of its own). I think this covers the main point that needs making and that details are already provided elsewhere. If this doesn't get it quite right or could use more detail, please let me know. Documentation on LOBs needs some fixes -- Key: DERBY-5696 URL: https://issues.apache.org/jira/browse/DERBY-5696 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.8.2.2 Reporter: Kim Haase Assignee: Kim Haase Attachments: DERBY-5696.diff, rrefjdbc96386.html DERBY-5489 points out some issues with multiple getXXX calls on LOBs that are not fully documented. The information should probably be added to Notes on mapping of java.sql.Blob and java.sql.Clob interfaces. In addition, the topic Mapping of java.sql.Blob and java.sql.Clob interfaces has a typo and could probably use some additional information as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5696) Documentation on LOBs needs some fixes
[ https://issues.apache.org/jira/browse/DERBY-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim Haase updated DERBY-5696: - Issue fix info: Patch Available Documentation on LOBs needs some fixes -- Key: DERBY-5696 URL: https://issues.apache.org/jira/browse/DERBY-5696 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.8.2.2 Reporter: Kim Haase Assignee: Kim Haase Attachments: DERBY-5696.diff, rrefjdbc96386.html DERBY-5489 points out some issues with multiple getXXX calls on LOBs that are not fully documented. The information should probably be added to Notes on mapping of java.sql.Blob and java.sql.Clob interfaces. In addition, the topic Mapping of java.sql.Blob and java.sql.Clob interfaces has a typo and could probably use some additional information as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5696) Documentation on LOBs needs some fixes
[ https://issues.apache.org/jira/browse/DERBY-5696?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262033#comment-13262033 ] Kim Haase commented on DERBY-5696: -- Sorry, the change is in the attached DERBY-5696.diff and rrefjdbc96386.html. Documentation on LOBs needs some fixes -- Key: DERBY-5696 URL: https://issues.apache.org/jira/browse/DERBY-5696 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.8.2.2 Reporter: Kim Haase Assignee: Kim Haase Attachments: DERBY-5696.diff, rrefjdbc96386.html DERBY-5489 points out some issues with multiple getXXX calls on LOBs that are not fully documented. The information should probably be added to Notes on mapping of java.sql.Blob and java.sql.Clob interfaces. In addition, the topic Mapping of java.sql.Blob and java.sql.Clob interfaces has a typo and could probably use some additional information as well. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bernard updated DERBY-5728: --- Attachment: NullParameterEclipseLinkDerbyMaven.zip EclipseLink Test Case Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 I am attaching an EclipseLink test case for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (DERBY-5728) Add Support for NULL IS NULL
bernard created DERBY-5728: -- Summary: Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 I am attaching an EclipseLink test case for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bernard updated DERBY-5728: --- Attachment: NullParameterHibernateDerbyMaven.zip Hibernate Test Case Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip, NullParameterHibernateDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 I am attaching an EclipseLink test case for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] bernard updated DERBY-5728: --- Description: The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 Please see EclipseLink and Hibernate test cases for verification. was: The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 I am attaching an EclipseLink test case for verification. Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip, NullParameterHibernateDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 Please see EclipseLink and Hibernate test cases for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262122#comment-13262122 ] Knut Anders Hatlen commented on DERBY-5728: --- Hi Bernard, Is this problem different from the one you reported in DERBY-5629? Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip, NullParameterHibernateDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 Please see EclipseLink and Hibernate test cases for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5728) Add Support for NULL IS NULL
[ https://issues.apache.org/jira/browse/DERBY-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13262224#comment-13262224 ] bernard commented on DERBY-5728: I think it it is different because it is more narrow in scope, it is an enhancement not a bug and does not leave open the question whether it might be an ORM bug that needs to be resolved. I hope this issue is easier to resolve. Add Support for NULL IS NULL Key: DERBY-5728 URL: https://issues.apache.org/jira/browse/DERBY-5728 Project: Derby Issue Type: Improvement Components: SQL Affects Versions: 10.8.2.2 Environment: Windows XP java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b05) Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing) Reporter: bernard Priority: Critical Attachments: NullParameterEclipseLinkDerbyMaven.zip, NullParameterHibernateDerbyMaven.zip The following query fails: SELECT ID FROM CUSTOMER WHERE ((NULL IS NULL) OR (NAME = NULL)) Why this is an issue? At least two major Java ORMs, Hibernate JPA and EclipseLink JPA have isues with generating SQL for trivial JPQL queries such as: select object(c) from Customer c where ((name: is null) or (c.name = name:)) where name: is a parameter For why this is a fundamental issue, please see a minimalistic JPQL query at http://en.wikipedia.org/wiki/Java_Persistence_Query_Language#Examples Part of this has already been resolved by issue Add support for setObject(arg, null) https://issues.apache.org/jira/browse/DERBY-1938 Please see EclipseLink and Hibernate test cases for verification. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
