You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2005/12/03 09:54:28 UTC
TCK : DeleteCallback
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, which can trigger a
further [pre/post]Store on the related instances (which aren't yet deleted,
since their turn has not come yet).
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 ?
--
Andy
Re: TCK : DeleteCallback
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: TCK : DeleteCallback
Posted by Michael Watzek <mw...@spree.de>.
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/
-------------------------------------------------------------------
Re: TCK : DeleteCallback
Posted by Craig L Russell <Cr...@Sun.COM>.
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.
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.
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!
Re: TCK : DeleteCallback
Posted by Michael Watzek <mw...@spree.de>.
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/
-------------------------------------------------------------------
Re: TCK : DeleteCallback
Posted by Craig L Russell <Cr...@Sun.COM>.
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!