Re: how to catch updates just before commit

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

Just checked in a fix for that:

http://issues.apache.org/cayenne/browse/CAY-544

As far as I can tell to-many relationship modifications no longer  
cause validateFor* invocations either.

Andrus


On Apr 30, 2006, at 11:02 AM, Bryan Lewis wrote:

> Alrighty then, I believe I found the difference.  My Company entity  
> has
> optimistic locking disabled.  ObjectDiff's constructor doesn't take
> singleArcSnapshots in that case, which leaves arcSnapshot an empty  
> map.
> The isNoop() method's visitSingleObjectArc() finds oldValue == null  
> and
> thinks there was a modification.
>
>
>
>
> Andrus Adamchik wrote:
>
>> We have unit tests that check this case, and they succeed, meaning
>> that somehow your Company object is different.
>>
>> If you have an opportunity to debug this on your own, validation
>> decisions are made inside a non-public
>> ObjectStoreGraphDiff.validateAndCheckNoop() which in turn calls
>> ObjectDiff.isNoop(). ObjectDiff should detect a phantom modification
>> and return "true".
>>
>> Otherwise please open a bug report attaching the Company object  
>> mapping.
>>
>> Andrus
>>
>>
>> On Apr 28, 2006, at 9:43 PM, Bryan Lewis wrote:
>>
>>> Yep, I understand that your suggestion was unrelated to CAY-414.   
>>> I  was
>>> answering two replies at once.
>>>
>>> I re-tested the phantom changes with the validateFor methods.  I   
>>> have a
>>> validating dataContext and my DataObject wedge class has a
>>> validateForUpdate() method that merely logs a message.  I  
>>> executed  this
>>> code:
>>>
>>>     Company company = (Company) DataObjectUtils.objectForPK(dc,
>>> "Company", new Integer(134987));
>>>     // Set the same value back again.
>>>     Boolean isActive = company.getIsActiveClient();
>>>     company.setIsActiveClient(isActive);
>>>     log.debug("B4 commitChanges");
>>>     dc.commitChanges();
>>>     log.debug("AF commitChanges");
>>>
>>> That produced this log:
>>>
>>>     B4 commitChanges
>>>     enter validateForUpdate(), object <ObjectId:Company,   
>>> NIC_ID=134987>
>>>     AF commitChanges
>>>
>>> So validateForUpdate() was called for a phantom change.  Note  
>>> that no
>>> SQL was generated, correctly.  This is with version 1.2B2.
>>>
>>> Then I thought perhaps my use of a Boolean property might be  
>>> confusing
>>> things because I have an extended type adapter to convert  
>>> Booleans to
>>> Integers.  I tried a String attribute:
>>>
>>>     String name = company.getName();
>>>     company.setName(name);
>>>
>>> Same result, validateForUpdate() was called but no SQL.  As a sanity
>>> check, I added a character to the name and did get SQL generated,  
>>> with
>>> the validate method called again of course.
>>>
>>>
>>> Andrus Adamchik wrote:
>>>
>>>>
>>>> On Apr 28, 2006, at 3:49 PM, Bryan Lewis wrote:
>>>>
>>>>> Hmm, I must be missing something.  I looked at CAY-414
>>>>
>>>>
>>>>
>>>> not ready to comment on that now. The validateFor* suggestion is
>>>> actually not related at all.
>>>>
>>>>> and looked for
>>>>> related changes in the latest code, but didn't grok it.  I  
>>>>> tried the
>>>>> validateFor methods, but they still get called for phantom
>>>>> changes... I
>>>>> tried adding to a to-many
>>>>
>>>>
>>>>
>>>> I think this one is a bug in the algorithm. Will need to  
>>>> investigate.
>>>>
>>>>
>>>>> and setting an attribute to its current value.
>>>>
>>>>
>>>>
>>>> Now this is strange. If you can confirm this behavior, then this  
>>>> is a
>>>> bug. I think you have other changes to the object in question  
>>>> though.
>>>>
>>>> Andrus
>>>
>>
>
>