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
>>>
>>
>
>
This archive was generated by hypermail 2.0.0 : Sun May 07 2006 - 16:12:08 EDT