Hello Craig,
please see my comments below...
Craig L Russell schrieb:
[..]
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
Why would we like to avoid immedate constraint violations in the first
place? They only constrain the user in that that he/she has to remove
objects from any associations before being able to delete them, and not
afterwards. Alternatively, if the user finds that uncomfortable, he
could make those FKs deferrable (if the DB allows it).
foreign key delete-action="" 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.
That sounds really very complicated. I'd wonder why someone would take
on the effort only to mimic real deferred constraints (for the case of
deletion only).
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?
That's what I had been wondering as well!
Regards,
Jörg
Comments?
|
