Hi Michael,
I agree with you point that it is reasonable for a user to expect an
atomic failure of "deleteObject". So I logged an improvement request
to re-implement this algorithm in 3.0:
https://issues.apache.org/cayenne/browse/CAY-866
I guess this wasn't deemed important on the assumption that a
DeleteDenyException is not recoverable. As I said, I am having second
thoughts about that, and see no reason why we can't make it atomic.
In the meantime your options are either to implement manual logic for
deletion or use a temp context.
Thanks
Andrus
On Sep 18, 2007, at 10:48 PM, Michael Gvirtzman wrote:
Hello,
I'm using combination of cascade / deny relationships, and trying
to introduce delete function. (I'm using version 2.)
In case a deny rule fires for one of the childs (within cascade
chain), I would expect deleteObject() to behave as transaction -
i.e., not to do any change; however it apparently doesn't: it fires
deny exception, but some of the childs (even those linked directly
to denying objects) are still deleted - and then later, during
commit, there is an error message due to foreign keys with deny rule.
(Note that childs not having deny links are deleted, creating
inconsistencies.)
What is your recommendation? I'm generally using a temporary
context to manage atomic in-memory transactions (with immediate
commit to parent upon success), and only once in a time save the
parent context to database; do I need to create atomic delete
transaction myself (copy the entire cascading tree to the temp
context, and only upon successful deletion commit changes to
parent)? Any other suggestion?
Thank you in advance,
Michael Gvirtzman.
