| Craig Russell (JIRA) 2005-12-26, 5:45 pm |
| [ http://issues.apache.org/jira/brows...action_12361244 ]
Craig Russell commented on JDO-220:
-----------------------------------
Committed revision 359106.
I've changed the test case to use a different persistence manager for each of the test methods. The test fails.
There are now two fetch groups: the first group includes only number1 and the second group includes only number2. In the first test method, with a new persistence manager, an instance is queried with fetch group 1 active. This should load only number1.
In the second test method, an instance is queried with fetch groups 1 and 2 active. This should load both fields number1 and number2. Then, group2 is removed from the fetch plan and the query is repeated. Now, only field number1 should be loaded.
> JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups
> ------------------------------------------------------------------------------------
>
> Key: JDO-220
> URL: http://issues.apache.org/jira/browse/JDO-220
> Project: JDO
> Type: Bug
> Components: tck20
> Reporter: Michael Watzek
> Assignee: Erik Bengtson
>
> Query test case GetFetchPlan fails throwing the exception below.
> The test case queries an instance of PCClass. PCClass has two persistent fields and two corresponding transient fields which are set by jdoPostLoad(). Furthermore, PCClass has two fetch groups. Each persistent field is contained in one of those fetch gr
oups. The test case checks if the queried instance has the right values wrt transient fields. This check fails.
> junit.framework.AssertionFailedError: Assertion A14.6-21 (FetchPan) failed: Field PCClass.number1 is in the default fetch group and should have been loaded. The jdoPostLoad() callback has copied the field value to a transient field which has an unexpect
ed value: 0
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.jdo.tck.query.api.GetFetchPlan.checkDefaultFetchGroup(GetFetchPlan.java:94)
> at org.apache.jdo.tck.query.api.GetFetchPlan.testPositive(GetFetchPlan.java:64)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at org.apache.jdo.tck.JDO_Test.runBare(JDO_Test.java:204)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> at junit.textui.TestRunner.doRun(TestRunner.java:116)
> at junit.textui.TestRunner.doRun(TestRunner.java:109)
> at org.apache.jdo.tck.util.BatchTestRunner.start(BatchTestRunner.java:120)
> at org.apache.jdo.tck.util.BatchTestRunner.main(BatchTestRunner.java:95)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secur...nistrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|