Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 338779 - After refresh/PU, object's state is represented by 2 identical revisions
Summary: After refresh/PU, object's state is represented by 2 identical revisions
Status: CLOSED FIXED
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 4.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Caspar D. CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-03-03 04:16 EST by Caspar D. CLA
Modified: 2011-06-23 03:39 EDT (History)
2 users (show)

See Also:
stepper: review+

Attachments
Testcase (as a patch) (3.94 KB, patch)
2011-03-03 04:23 EST, Caspar D. CLA 		no flags Details | Diff
Patch v1 (6.92 KB, patch)
2011-03-08 23:20 EST, Caspar D. CLA 		no flags Details | Diff
Show Obsolete (2) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Caspar D. CLA 2011-03-03 04:16:47 EST 
Using PU=false or PU=true with puMode=CHANGES/ADDITIONS, the result
of a refresh or commitNotification, is that both a new revision is
added to the revisionCache, and the revision currently backing the
object (i.e. the one returned by obj.cdoRevision()) is updated.

The object's data state thus ends up being represented twice in the
client's memory. While I haven't noticed any obvious breakage as a
consequence of this, it doesn't seem right to me.
Comment 1 Caspar D. CLA 2011-03-03 04:22:35 EST 
Note that I'm talking about a clean object here. In general, I
think it should hold for clean objects that if obj.cdoRevision()
returns rev, then

rev == revMgr.getRevisionByVersion(rev.getID(), rev, 0, false);

If this doesn't hold (as my forthcoming testcase will demonstrate),
then the rev in the revMgr is a waste of memory.
Comment 2 Caspar D. CLA 2011-03-03 04:23:02 EST 
Created attachment 190248 [details]
Testcase (as a patch)
Comment 3 Eike Stepper CLA 2011-03-03 06:17:28 EST 
I wonder if this can even be harmful when the only immutability of a revision kicks in: setRevised(long)
Comment 4 Caspar D. CLA 2011-03-08 23:20:30 EST 
Created attachment 190726 [details]
Patch v1

IMO the state machine needs to get out of the delta-application
business. This patch arranges that.
Comment 5 Caspar D. CLA 2011-03-09 03:55:30 EST 
Committed revision 7428.
Comment 6 Eike Stepper CLA 2011-06-23 03:39:22 EDT 
Available in R20110608-1407