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 : Sat Apr 29 2006 - 09:16:48 EDT