Re: can't modify relationships in validateForUpdate()?

From: Bryan Lewis (brya..aine.rr.com)
Date: Tue Nov 28 2006 - 14:01:20 EST

  • Next message: Øyvind Harboe: "Problems with prepared statements"

    That's great. Except... does anyone have tips for building the new
    cayenne? The new "Compiling Cayenne" wiki page is unfinished. I had
    no trouble with the old ant build.

    I got close, I think. I installed maven and checked out the source from
    svn, and got it to almost build. (After commenting out the
    "cayenne-osx" line of assembly/pom.xml. Sensible?) After 28 minutes of
    churning :-) it produced a few jars like
    cayenne-jdk1.4-3.0-incubating-SNAPSHOT.jar, but none of them look like
    the good old cayenne.jar; they don't include externals such as log4j for
    example. I'm probably missing some step.

    I tried the old ant way. The wiki suggests that it will still work from
    the cayenne-ant directory, but I get an immediate error:

      prepare-deps:
          [unjar] Expanding:
    C:\cayenne-svn\cayenne\pre-maven\cayenne-java\lib\velocity-dep-1.3.jar into
            C:\cayenne-svn\cayenne\pre-maven\cayenne-ant\build\cayenne-1_4\deps

    Andrus Adamchik wrote:
    > I just checked in the fix. Also I described in the docs how validation
    > should behave when user methods have side effects:
    >
    > http://cwiki.apache.org/CAYDOC/dataobject-validation.html
    >
    > Andrus
    >
    > On Nov 27, 2006, at 8:23 PM, Bryan Lewis wrote:
    >
    >> Thanks! I entered an issue CAY-712.
    >>
    >>
    >> Andrus Adamchik wrote:
    >>> Actually IIRC we did allow to do arbitrary modifications to objects
    >>> within "validate*" at some point. And checking the code, I see where
    >>> you getting this exception now.
    >>>
    >>> Could you please submit a bug report? It should be fairly easy to fix
    >>> it (although it will add a bit of overhead on commit, as we will have
    >>> to copy dirty objects in a separate collection). Also this time around
    >>> we'll try to add a unit test, so that it doesn't get lost again :-)
    >>>
    >>> Andrus
    >>>
    >>>
    >>> On Nov 27, 2006, at 12:31 PM, Bryan Lewis wrote:
    >>>> We have some code in a DataObject's validateForUpdate() method that
    >>>> modifies the object's relationships. It had been working fine for
    >>>> over
    >>>> a year, although it's not exercised very often because it's only
    >>>> called
    >>>> when an employee leaves. Today it threw a ConcurrentModification, so
    >>>> I'm guessing there was some related change in Cayenne in the last few
    >>>> months. It reminds me of the guideline we used to follow with our old
    >>>> WebObjects apps, shouldn't modify an object in -validateForSave...
    >>>> maybe
    >>>> now that's a good rule in Cayenne too?
    >>>>
    >>>>
    >>>> public void validateForUpdate(ValidationResult validationResult)
    >>>> {
    >>>> DataContext dc = getDataContext();
    >>>> DataRow oldData =
    >>>> dc.getObjectStore().getSnapshot(this.getObjectId());
    >>>> Boolean oldIsActive = (Boolean) oldData.get("ISACTIVE");
    >>>> Boolean newIsActive = getIsActive();
    >>>> // If the employee is being made inactive...
    >>>> if (oldIsActive.equals(Boolean.TRUE) &&
    >>>> newIsActive.equals(Boolean.FALSE)) {
    >>>> // Clear the employee's roles.
    >>>> // Use a ListIterator to allow concurrent modification.
    >>>> for (ListIterator it = getRoles().listIterator();
    >>>> it.hasNext(); ) {
    >>>> Role role = (Role) it.next();
    >>>> it.remove();
    >>>> removeFromRoles(role);
    >>>> }
    >>>> }
    >>>> }
    >>>>
    >>>>
    >>>> The exception:
    >>>>
    >>>> org.objectstyle.cayenne.access.ObjectStoreGraphDiff.validateAndCheckNoop(ObjectStoreGraphDiff.java:109)
    >>>>
    >>>>
    >>>> org.objectstyle.cayenne.access.DataContext.flushToParent(DataContext.java:1244)
    >>>>
    >>>>
    >>>> org.objectstyle.cayenne.access.DataContext.commitChanges(DataContext.java:1165)
    >>>>
    >>>>
    >>>>
    >>>> This is with Cayenne 1.2.1.
    >>>>
    >>>>
    >>>
    >>
    >>
    >



    This archive was generated by hypermail 2.0.0 : Tue Nov 28 2006 - 14:02:18 EST