db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Assertion A14.6-21 (Query.getFetchPlan)
Date Wed, 26 Oct 2005 10:45:53 GMT
Hi Michael,

Craig

On Oct 25, 2005, at 5:55 AM, Michael Watzek wrote:

> Hi Craig,
>
>
>> Hi Michael,
>> The relevant bit of the specification is regarding jdoPostLoad.   
>> A10.1-2 [This method is not modified by the enhancer.]
>> So whatever is done in jdoPostLoad, the implementation will not  
>> be  called "transparently".
>> But the spec doesn't require jdoPostLoad to be called if only  
>> fetch  group A is active.
>>
> My understanding of the spec is that this is controled by attribute  
> post-load of element fetch-group. That's why I set it to true in my  
> example below.
>
> There might be a typo related to fetch groups in chapter 12.7.2,  
> the last sentence of the first paragraph:
>
> "The callback will be called if an instance is loaded when any  
> fetch group is active that contains the fetch-group set to true."
>
> Shouldn't it say "... that contains the post-load set to true." ?

Yes, this is a typo in the spec. I've corrected it.
>
>
> A better test might be to define the default fetch
>
>> group explicitly as not having the fields, and define fetch group  
>> A  as having the fields. Then you can have the default fetch group  
>> (not  fetch any fields) invoke jdoPostLoad, but test that fetch  
>> group A  fields have been loaded.
>>
> I agree that a default fetch group having no fields is better than  
> removing the default fetch group from the query fetch plan.

This is fine. I think the important thing is that both conditions are  
true: the jdoPostLoad is called; and the field in fetch group A but  
not in the default fetch group has a value from the database.

Craig

>
> Regards,
> Michael
>
>> Craig
>> On Oct 20, 2005, at 7:41 AM, Michael Watzek wrote:
>>
>>> Hi,
>>>
>>> assertion A14.6-21 specifies:
>>>
>>> "This method retrieves the fetch plan associated with the Query.  
>>> It  always returns the identical instance for the same Query  
>>> instance.  Any change made to the fetch plan affects subsequent  
>>> query execution."
>>>
>>> I wonder, how the second part of this assertion can be tested.  
>>> Does  the following idea make sense:
>>>
>>> A class PC defines a fetch group A with post-load true. Class PC   
>>> defines a postLoad callback which sets a transient field for  
>>> each  persistent field.
>>>
>>> The test case creates a query instance having candidate class  
>>> PC.  Afterwards, it retrieves the fetch plan, removes the default  
>>> fetch  group and adds fetch group A. Then, it executes the query.
>>>
>>> Finally, the test case checks for each returned query instance,  
>>> if  the transient fields which correspond with persistent fields  
>>> of  fetch group A have the right values.
>>>
>>> Would this work, or would the persistent field access in  
>>> postLoad  retrieve values from the database for non-loaded fields?
>>>
>>> Regards,
>>> Michael
>>> -- 
>>> -------------------------------------------------------------------
>>> Michael Watzek                  Tech@Spree Engineering GmbH
>>> mailto:mwa.tech@spree.de        Buelowstr. 66
>>> Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
>>> Fax.:  ++49/30/217 520 12       http://www.spree.de/
>>> -------------------------------------------------------------------
>>>
>>>
>
>
> -- 
> -------------------------------------------------------------------
> Michael Watzek                  Tech@Spree Engineering GmbH
> mailto:mwa.tech@spree.de        Buelowstr. 66
> Tel.:  ++49/30/235 520 36       10783 Berlin - Germany
> Fax.:  ++49/30/217 520 12       http://www.spree.de/
> -------------------------------------------------------------------
>


Mime
View raw message