Re: Delete Object Issue

From: Andrus Adamchik (
Date: Wed Sep 19 2007 - 06:03:05 EDT

  • Next message: Gary Jarrel: "Temp ID issue - Exception"

    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:

    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.


    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