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.
|
smime.p7s
Description: S/MIME cryptographic signature
