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

Reply via email to