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.
This archive was generated by hypermail 2.0.0 : Wed Sep 19 2007 - 06:03:30 EDT