Re: [jira] Commented: (JDO-220) JPOX does not call jdoPostLoad() on queried instances or does not load fetch groups

[Craig L Russell]

Hi Andy, You are right. Thanks for pointing out that section 10.1 was not updated for JDO 2. <spec> A10.1-1 [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. A10.1-2 [This method is not modified by the enhancer.] 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> <proposed> A10.1-1 [This method is called after values have been loaded from the StateManager into the instance, if an active fetch group has been defined with the post-load attribute set to true.] Non-persistent fields whose value depends on values of loaded fields should be initialized in this method. A10.1-2 [This method is not modified by the enhancer.] Only fields that are loaded by an active 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. </proposed> Craig On Dec 27, 2005, at 2:03 AM, Andy Jefferson (JIRA) wrote:     [ http://issues.apache.org/jira/browse/JDO-220?page=comments#action_12361260 ]  Andy Jefferson commented on JDO-220: ------------------------------------ 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. 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 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) --  This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators:    http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see:    http://www.atlassian.com/software/jira Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature