Hi,
I like to propose a solution for JIRA JDO-48 (http://issues.apache.org/jira/browse/JDO-48).
Actually, JDO-48 describes two issues:
1) Query tests fail cleaning up the database because of a foreign key constraint violation. The reason is that HollowInstanceMaintainsPK does not clean up the database.
2) Different TCK tests have different strategies for clean up.
This proposal fixes issue 2) and, as a side effect, issue 1) also.
Current status:
Class JDOTest is the super class of all TCK tests. Amongst others, this class defines methods setUp() and tearDown(). Method setUp() creates the PMF instance. Method tearDown() closes the PM instance (created by tests) and it closes the PMF instance. Furthermore, method tearDown() implements the semantics that takes care for throwing the right exception in case of tests and/or tear down failures: Exceptions during tear down do not affect the test result in case of test failures. In such cases, method tearDown() logs exceptions. However, if tests succeed and tearDown() throws an exception then that exception determines the test result.
Problem:
Some tests override method tearDown() cleaning up the database, some tests clean up the database inside the test methods (testXXX).
Proposal:
The objective of this proposal are:
1) Tests should not need to override method tearDown() as the semantics is not trivial and error-prone. Instead, tests have hooks into setUp() and tearDown(). There, they may allocate/release resources and/or data.
2) Tests may register created (persistent) data. That data is cleaned up automatically during tearDown().
Solution:
1) We add 2 methods to class JDOTest localSetUp() and localTearDown(). These methods are called by setUp() and by tearDown(). They are hooks into the two methods and they may be overridden by subclasses.
2) Furthermore, we add 2 methods to class JDOTest which may be used for registering persistence capable instances and persistence capable classses. The default implementation of localTearDown() cleans up all registered persistent data.
3) We change all tests in order to comply to 1) and 2).
Obviously, issue 3) is most time-consuming. For this reason, I suggest to solve 1) and 2) in a first step. In a second step, we solve issue 3) per TCK package, e.g. starting with "org.apache.jdo.tck.lifecycle".
What do you think?
Regards, Michael -- ------------------------------------------------------------------- Michael Watzek [EMAIL PROTECTED] Engineering GmbH mailto:[EMAIL PROTECTED] Buelowstr. 66 Tel.: ++49/30/235 520 36 10783 Berlin - Germany Fax.: ++49/30/217 520 12 http://www.spree.de/ -------------------------------------------------------------------
