Delete Object Issue

[Michael Gvirtzman <mi...@bezeqint.net>]

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.

Re: Delete Object Issue

[Andrus Adamchik <an...@objectstyle.org>]

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.