Sounds like a plan.
Andrus
On Sep 23, 2008, at 12:27 PM, Andrey Razumovsky wrote:
> 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:29:46 EDT