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 Behavior of deletePersistent with datastore constraints
Date Tue, 11 Jul 2006 20:52:59 GMT
Javadogs,

JDO assumes that during a transaction, the persistent instances in  
memory might be out of sync with the persistent instances in the  
datastore. The application does not need to be written so as to  
guarantee consistency with each individual memory operation.

The spec is pretty specific about when instances are removed from the  
datastore:

<spec 12.6.7>
These methods delete persistent instances from the datastore. They  
must be called in the
context of an active transaction, or a JDOUserException is thrown.  
The representation
in the datastore will be deleted when this instance is flushed to the  
datastore (via commit
or evict).
...
If deleting an instance would violate datastore integrity  
constraints, it is implementation-
defined whether an exception is thrown at commit time, or the delete  
operation is simply
ignored. Portable applications should use this method to delete  
instances from the datas-
tore, and not depend on any reachability algorithm to automatically  
delete instances.
</spec 12.6.7>

I'd like to discuss the two items above. The spec requires that  
deletes be deferred until flush, but I suspect that this  
overconstrains the possible implementations. I would leave it up to  
the implementation to decide whether to delete immediately or defer  
until flush.

But if it deletes the instance immediately, it would also have to  
nullify any foreign keys that refer to it in order to avoid an  
immediate constraint violation. And I don't believe that this should  
be done automatically unless the user specifically asked for it, via  
a metadata annotation on the foreign key delete-action=NULL. If the  
implementation wanted to nullify the referring key where the  
constraint was defined as anything else, it would have to guarantee  
at flush time that the user had set the field to null or something  
else, or all the referring objects themselves were deleted.

With regard to integrity constraints, the second paragraph leaves me  
cold. I don't know what I was thinking when I wrote "or the delete  
operation is simply ignored". When would ignoring a delete from the  
application ever be the right behavior?

Comments?

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