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: TCK : DeleteCallback
Date Tue, 06 Dec 2005 15:11:16 GMT
Hi Michael,

You're right. I swear I looked for this.events.add(event) and missed  
it from postStore. :-(

Thanks,

Craig

On Dec 6, 2005, at 1:42 AM, Michael Watzek wrote:

> Hi Craig,
>
>> Hi,
>> On Dec 5, 2005, at 7:40 AM, Michael Watzek wrote:
>>> 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.
>> Given that the relationships are represented by foreign keys in  
>> the database for which the delete rule is specified as RESTRICT,  
>> this is true.
>>>
>>> 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.
>> This seems to be a good solution.
>>>
>>> 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.
>> The test case org/apache/jdo/tck/query/delete/DeleteCallback.java  
>> as checked in seems to ignore the preStore and postStore callbacks.
> Actually, the test case ignores preStore events and preDelete  
> events. postStore events and postDelete events are added to an  
> event list. The event list is analysed by method  
> verifyCallbacksAndStates() at a later time.
>
>>         public void preStore(InstanceLifecycleEvent event) {
>>             if (logger.isDebugEnabled()) {
>>                 logger.debug("preStore event: " +
>>                         JDOHelper.getObjectId(event.getSource()));
>>             }                          }                  public  
>> void postStore(InstanceLifecycleEvent event) {
>>             this.events.add(event);
>>             if (logger.isDebugEnabled()) {
>>                 logger.debug("postStore event: " +
>>                         JDOHelper.getObjectId(event.getSource()));
>>             }                  }      }              Another issue  
>> (minor) is the typo in the inner class name. Should be private  
>> class LifecycleVerifier.
> I'll fix it.
>
> Regards,
> Michael
>> Regards,
>> Craig
>>>
>>> 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/
>>> -------------------------------------------------------------------
>> 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/
> -------------------------------------------------------------------

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!


Mime
View raw message