I even think this should be closed since changing behavior will result in
slowlyness..
2009/2/19 Andrus Adamchik <andru..bjectstyle.org>
> 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.ObjectDif..33d68a
>>> {}
>>> null
>>> 1
>>> null
>>> <ObjectId:Announcement, ANNOUNCEMENT_ID=200>
>>> org.objectstyle.cayenne.access.ObjectStor..0cf
>>> 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.
>>
>>
>>
>
This archive was generated by hypermail 2.0.0 : Thu Feb 19 2009 - 08:24:06 EST