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: TCK : DeleteCallback
Date Mon, 05 Dec 2005 15:40:16 GMT
Hi Craig, Andy

I think there is a portability issue with this test case:

The test case assumes that a JDO implementation supports managed 
relationships, because it deletes instances which are referenced by 
other instances. Due to the fact that it does not nullify those 
references explicitely, the test will cause errors for JDO 
implementations which do not support managed relationships.

In order to make the test case portable, it should explicitely nullify 
references to the all deleted objects first. Afterwards, it should call 
Query.deletePersistentAll.

I think that the problem you discussed below will not show up after this 
change because all updates would have been initiated explicitely by the 
test case.

What do you think?

Regards,
Michael
> Hi Andy,
> 
> On Dec 3, 2005, at 12:54 AM, Andy Jefferson wrote:
> 
>> The DeleteCallback test when using relationships is apparently 
>> insisting that 
>> no [pre/post]Store event is ever fired after the first [pre/post]Delete 
>> event. I'd like to confirm why this is the case. 
>>
>> JPOX does the following :-
>>
>> 1. Query.deletePersistentAll() called, so we flush all instances 
>> passed in 
>> (this flushing is not in JPOX CVS as yet).
>> 2. [pre/post]Store are called on all flushed instances.
>> 3. deletePersistent is called on the first instance. This can cause 
>> updates to 
>> related instances since the instance is now deleted,
> 
> 
> I understand that deleting a referred instance makes the cache 
> inconsistent with the datastore, but don't see anything in the 
> specification that provides for the change to be reflected immediately 
> via a flush. JDO doesn't disallow managing relationships. But flushing 
> the changes is unexpected. 
> 
>> which can trigger a 
>> further [pre/post]Store on the related instances (which aren't yet 
>> deleted, 
>> since their turn has not come yet).
> 
> 
> Flushing behavior is described in 12.8 (explicit persistence manager 
> flush()). Automatic flushing of instances to the datastore is not 
> described anywhere. Flushing for evict, commit, and query is described.
> 
>>
>> Where exactly does it say in the spec that a JDO implementation cannot 
>> fire 
>> off further [pre/post]Store on related instances during the deletion 
>> process ? i.e the JDO2 spec is expecting the implementation to turn off 
>> reporting of events on all instances in the process of being deleted ?
> 
> 
> No, it is expecting that flushing is done at specific times (evict, 
> commit, query, and user-initiated) and not at other times. 
> 
> Craig
> 
>>
>>
>> -- 
>> Andy
> 
> 
> Craig Russell
> 
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 
> 408 276-5638 mailto:Craig.Russell@sun.com
> 
> P.S. A good JDO? O, Gasp!
> 
> 


-- 
-------------------------------------------------------------------
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