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
>>
>
This archive was generated by hypermail 2.0.0 : Sun Apr 30 2006 - 11:03:07 EDT