I even think this should be closed since changing behavior will result in slowlyness..
2009/2/19 Andrus Adamchik <[email protected]> > So it works correct, provided "artist.setName(artist.getName());" pushes >> object to modified state. The problem is that isNoop() can work slowly, so >> we likely don't want to fire it always when hasChanges() is called. >> > > +1. > > > > On Feb 19, 2009, at 7:31 AM, Andrey Razumovsky (JIRA) wrote: > > >> [ >> https://issues.apache.org/cayenne/browse/CAY-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13248#action_13248 >> ] >> >> Andrey Razumovsky commented on CAY-512: >> --------------------------------------- >> >> Hi Øyvind, >> >> The javadoc in hasChanges() says: >> "Returns <code>true</code> if there are any modified, deleted or new >> objects registered with this DataContext". >> >> So it works correct, provided "artist.setName(artist.getName());" pushes >> object to modified state. The problem is that isNoop() can work slowly, so >> we likely don't want to fire it always when hasChanges() is called. >> >> A new method, however, would be useful >> >> >> >> Keep DataObjects in commited state for no-op writeProperties >>> ------------------------------------------------------------ >>> >>> Key: CAY-512 >>> URL: https://issues.apache.org/cayenne/browse/CAY-512 >>> Project: Cayenne >>> Issue Type: Improvement >>> Components: Cayenne Core Library >>> Affects Versions: 1.2 branch >>> Environment: M9-B1 >>> Reporter: Mike Kienenberger >>> Assignee: Andrus Adamchik >>> Fix For: Undefined future >>> >>> >>> Regression: Cayenne M9+ sets DataObjects as "modified" during no-op >>> writeProperties >>> writeProperty("x", "y") puts dataObject into a modified state when "y" >>> was already the value of "x" before the method call. >>> Before M9, object would remain in committed state. >>> Object in my ObjectStore: >>> <ObjectId:Announcement, ANNOUNCEMENT_ID=200>={<ObjectId:Announcement, >>> ANNOUNCEMENT_ID=200>; modified; [enabled=>Y; description=>SNAP; >>> contentList=>(..); effectiveEndDate=>Mon Oct 31 00:00:00 EST 2005; >>> effectiveStartDate=>Thu Sep 01 00:00:00 EDT 2005; >>> qualifiedViewpointList=>(..)]} >>> ObjectDiff of record -- appears to indicate that nothing has changed. >>> Same as the other 4 restored objects. >>> Comparision of snapshot values to object store values shows nothing >>> different. >>> value= ObjectDiff (id=3310) >>> arcSnapshot= HashMap (id=3311) >>> currentArcSnapshot= null >>> diffId= 1 >>> flatIds= null >>> nodeId= ObjectId (id=3309) >>> objectStore= ObjectStore (id=3200) >>> otherDiffs= null >>> snapshot= HashMap (id=3312) >>> org.objectstyle.cayenne.access.objectd...@133d68a >>> {} >>> null >>> 1 >>> null >>> <ObjectId:Announcement, ANNOUNCEMENT_ID=200> >>> org.objectstyle.cayenne.access.objectst...@c0cf >>> null >>> {enabled=Y, description=SNAP, effectiveEndDate=Mon Oct 31 00:00:00 EST >>> 2005, effectiveStartDate=Thu Sep 01 00:00:00 EDT 2005} >>> A workaround has been to add code in my BaseDataObject class to check >>> for the old value equaling the new value in writeProperty(), and if >>> so, do nothing. >>> >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> >
