Re: [jira] Created: (CAY-1109) Non-physical delete (through update) does not work properly

From: Mike Kienenberger (mkienen..mail.com)
Date: Mon Sep 22 2008 - 14:22:41 EDT

  • Next message: Andrey Razumovsky: "Re: [jira] Created: (CAY-1109) Non-physical delete (through update) does not work properly"

    For what it's worth, I've been doing something similar since Cayenne 1.1.
    How I handled it was to invalidate any objects pointing to the deleted object.

    On Fri, Sep 19, 2008 at 9:12 AM, Andrey Razumovsky (JIRA)
    <de..ayenne.apache.org> wrote:
    > Non-physical delete (through update) does not work properly
    > -----------------------------------------------------------
    >
    > Key: CAY-1109
    > URL: https://issues.apache.org/cayenne/browse/CAY-1109
    > Project: Cayenne
    > Issue Type: Bug
    > Components: Cayenne Core Library
    > Affects Versions: 3.0
    > Reporter: Andrey Razumovsky
    > Assignee: Andrus Adamchik
    > Fix For: 3.0
    > Attachments: test-CAY-1109.txt
    >
    > I've got reasons to keep all records in database, even those user had deleted. As a solution, I have a field called "deleted" which is 0 by default and 1 if user had removed the data. To show only object with 'deleted = 0' I add this qualifier to all objEntities. Finally, I call setDeleted('1') instead of context.deleteObject()
    >
    > The problem is that after I invoke setDeleted("1") and commit, part of Cayenne thinks that the object is deleted (and I'd agree with it) while another part thinks it is not. Personally I think that setting qualifier means that I cannot have registered objects that do not match this qualifier.
    >
    > I've uploaded a test which shows that other side of relationships with such objects is not updated properly. This test should succeed.
    > Even worse, sometimes (I failed to create a test by now) I get this unfamous exception:
    >
    > org.apache.cayenne.FaultFailureException: [v.3.0M4 May 18 2008 16:32:02]
    > Error resolving fault, no matching row exists in the database for ObjectId:
    > <ObjectId:Apkforecast, apkforecastid=3>
    >
    > at org.apache.cayenne.BaseContext.prepareForAccess(BaseContext.java:100)
    > at com.nic.rainbow.data.auto._Apkforecast.getDate(_Apkforecast.java:29)
    >
    >
    > My suggestion is that we check declared qualifier after CDO update, and if it does not match, unregister object and process delete rules.
    >
    > --
    > This message is automatically generated by JIRA.
    > -
    > You can reply to this email to add a comment to the issue online.
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Sep 22 2008 - 14:23:30 EDT