Re: how to catch updates just before commit

From: Andrus Adamchik (andru..bjectstyle.org)
Date: Sun May 07 2006 - 16:11:38 EDT

  • Next message: Kevin Menard: "Re: CVS migrated to Apache Subversion"

    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