So let the solution be:
- Check the qualifier at update and if it does not match:
1. Unregister the object the same way it is done with objects marked as
deleted.
2. Invalidate all relationships pointing to this object. I really wish we
could process delete rules, but obviously we cannot do CASCADE here, because
we don't know how to delete those related objects. So for now that'll be
invalidation (or I think we could perform NULLIFY instead of CASCADE).
I'll have a look when I'll have some time (and rights) for that.
2008/9/22, Mike Kienenberger <mkienen..mail.com>:
>
> 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 : Tue Sep 23 2008 - 05:28:10 EDT