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

Bug 329503

Summary: Danger of losing edits when saving resources
Product: [Technology] STEM Reporter: Stefan Edlund <sedlund>
Component: UIAssignee: Stefan Edlund <sedlund>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: P3 CC: mattadav
Version: unspecified   
Target Milestone: 1.1.2   
Hardware: All   
OS: All   
Whiteboard:

Description Stefan Edlund CLA 2010-11-04 19:06:32 EDT 
Steps to recreate:

1. Create a model M1. This will open the editor for the model
2. Create a model M2. This will open the editor for the model
3. Drag M2 into M1 (i.e. M2 is a child of M1). Save M1.
4. Drag a decorator into M2 and save M2.
5. Without closing and reopening the editor for M1 (you will notice that if you expand M2 the new decorator is NOT showing), drag another decorator into M1 and save M1.
6. Close and re-open the editor for M2. You will notice that the decorator is gone. Also, if you look at M2 in the project explorer the decorator is gone.

Ideal solution:

In step 5 when the user activates the editor for M1, the content should automatically be reloaded to ensure that the new decorator shows up under M2. A popup question such as "Model M2 has been modified, refresh?" is also okay.

I'm giving this one major priority since I've hit the problem so many times.
Any advice on how to fix is appreciated!
Comment 1 Stefan Edlund CLA 2010-11-04 19:24:20 EDT 
To me
Comment 2 Stefan Edlund CLA 2010-11-05 12:48:21 EDT 
*** Bug 312675 has been marked as a duplicate of this bug. ***
Comment 3 Stefan Edlund CLA 2010-11-08 23:02:07 EST 
The following has been fixed:

1. You do not lose edits when saving a parent model on top of a sub model the way described in the defect.

2. The project explorer now keeps track of changes to models and scenarios without closing the nodes in the trees. Changes should show up immediately when they are saved in the editors

The ideal solution described in the defect is not working yet though, and the editors could still show stale data. But the edits won't be lost at least. Here is one problem that still shows up:

1. Open an editor for model M2 containing some content, for instance a decorator
2. Open an editor for a model M1 containing model M2. DO NOT EXPAND THE TOP LEVEL NODE.
3. Go back to the M2 editor and remove the decorator, then save M2
4. Go back to the M1 editor and open the top node then the M2 node. A "ghost" decorator with an ID that looks randomly generated shows up. 

If you close and reopen the M1 editor the problem goes away.

I've also sporadically seen tree nodes in the project explorer with an empty name, but this seems difficult to reproduce. Refreshing the project seems to fix this.

I will lower the severity of this bug to normal, since the edit losses seems fixed. However, I think we should fix the other (less severe) problems.
Comment 4 Stefan Edlund CLA 2010-11-09 17:53:21 EST 
Looks like I spoke to early. I see data still being lost occasionally, I suspect there might be a race condition somewhere in the code. Will raise the severity again, but not sure if I can do much before the demo this week.
Comment 5 Stefan Edlund CLA 2011-01-06 18:53:43 EST 
The source of the problem is an EMF bug, and a bugzilla has been opened against it (333711)

More information is available in this thread:

http://www.eclipse.org/forums/index.php?t=msg&goto=647546&S=44f04262c14bea4fd44a01d0a1d62f32#msg_647546
Comment 6 Matthew Davis CLA 2012-01-17 16:58:44 EST 
I've committed a proposed additional fix for the "random disappearance of resources from children resources", but in high impact code that will need thorough testing.

Actual Bug Circumstance:  Completely unresolved proxy references do not get serialized as part of their parent resource.

XMLSaveImpl calls the getHREF() method from XMLHelper to get a save path for proxy reference.  In STEM, we override XMLHelper in STEMXMIResourceFactoryImpl.  If getHREF() returns null, XMLSaveImpl skips & does not serialize the proxy ref.

In the overridden getHREF() method, we call getURI() on the Identifiable.  If the URI is null, then getHREF() returns null.  If the proxy is unresolved, getURI() returns null.  For proxies, we return eProxyUri() for the href - which is correct.  However that happens after the URI null check - so unresolved proxies return a null href.

The proposed fix is to return eProxyUri() for proxies without checking for a null URI.
Comment 7 Stefan Edlund CLA 2012-04-16 17:03:18 EDT 
Fix verified.