db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Watzek <mwa.t...@spree.de>
Subject Re: Assertion A14.6-21 (Query.getFetchPlan)
Date Tue, 25 Oct 2005 12:55:42 GMT
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." ?


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.

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