cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Lewis <br...@maine.rr.com>
Subject Re: how to catch updates just before commit
Date Sun, 30 Apr 2006 15:02:24 GMT
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
>>
>


Mime
View raw message