JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups

• Key: JDO-220
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Andy Jefferson
• Reporter: Michael Watzek
• Component/s: tck2

Description

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 groups. 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 unexpected 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)

Comments

[Andy Jefferson]

The second of the fields ("number2") is checked that it is not loaded. So what about the case where the object has been pulled from the cache ? The field "number2" will still be loaded and consequently that part of the test will fail.

[Craig Russell]

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.

[Andy Jefferson]

Hi Craig,
With the improved tests the reason why it fails is that JPOX calls jdoPostLoad() based on whether the DFG is loaded and not whether the current fetch plan is loaded, which is logically incorrect since JDO2 uses fetch plans in general. If I then refer to the spec (section 10.1) I see that
<spec>
jdoPostLoad
This method is called after the default fetch group values have been loaded from the StateManager into the instance. Non-persistent fields whose value depends on values of default fetch group fields should be initialized in this method. Only fields that are in the default fetch group should be accessed by this method, as other fields are not guaranteed to be initialized. This method might register the instance with other objects in the runtime environment.
</spec>
So consequently JPOX is strictly speaking sticking to the spec :-)

I suggest that references to "default fetch group" in this section be changed to "current fetch plan", and in the meantime I can correct JPOX behaviour to use that definition.

[Andy Jefferson]

Fixed in JPOX CVS - get a build dated 28/12/2005 or later.
Both GetFetchPlan tests now pass.

[Andy Jefferson]

Reopen issue since it failed to move to "Resolved" when asked to yet no longer shows the "Resolve Issue" option ... Apache JIRA problem by the look of it

[Andy Jefferson]

Fixed in JPOX CVS - builds dated 28/12/2005 or later.
Both GetFetchPlan tests now pass