Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338779

Summary:

After refresh/PU, object's state is represented by 2 identical revisions

Product:

[Modeling] EMF

Reporter:

Caspar D. <caspar_d>

Component:

cdo.core

Assignee:

Caspar D. <caspar_d>

Status:

CLOSED FIXED

QA Contact:

Eike Stepper <stepper>

Severity:

normal

Priority:

CC:

saulius.tvarijonas, stepper

Version:

4.0

Flags:

stepper: review+

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
Testcase (as a patch)	none
Patch v1	none

Description Caspar D.

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.

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.

2011-03-03 04:23:02 EST

Created attachment 190248 [details]
Testcase (as a patch)

Comment 3 Eike Stepper

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.

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.

2011-03-09 03:55:30 EST

Committed revision 7428.

Comment 6 Eike Stepper

2011-06-23 03:39:22 EDT

Available in R20110608-1407