Bugzilla – Full Text Bug Listing
| Summary: | [Diagram] Artifact refactoring doesn't update all references on diagrams | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Technology] Tigerstripe | Reporter: | Navid Mehregani <nmehrega> | ||||||||||||
| Component: | UI | Assignee: | Yuri Strot <yuri> | ||||||||||||
| Status: | VERIFIED FIXED | QA Contact: | |||||||||||||
| Severity: | major | ||||||||||||||
| Priority: | P3 | CC: | chrhartl | ||||||||||||
| Version: | unspecified | ||||||||||||||
| Target Milestone: | 0.5M0 | ||||||||||||||
| Hardware: | PC | ||||||||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||||||||
| Whiteboard: | |||||||||||||||
| Attachments: |
|
||||||||||||||
|
Description
Navid Mehregani
Dan, can you please take a look at this in the next iteration? Thanks! Some of the work that was done in bug#326452 is related to this. Suggest this should be upgraded to major as it will 'corrupt' the model. Upgrading to Major. I have this defect in my list as a candidate for the next iteration. Created attachment 182263 [details]
patch_327698.txt
Fixes a number of issues related to synchronization (Hopefully All!). I was unable to make this patch get out of sync with any model changes(Rename or Move) both with open or closed diagrams.
Classes Changed:
ModelChangeDeltaProcessor
ClassDiagramSynchronizer
ProjectDiagramSynchronizer
ArtifactFQRenameRequest
The patch file makes it look like a whole lot has changed in ModelChangeDeltaProcessor, but really just a few lines at line 189, Added the If/Else block now at line 198 and some variable setup before that.
Excellent - it will be good to try this out and I'll certainly let you know if there are any remaining issues. Created attachment 182427 [details]
patch_327698.txt
New patch: merged ModelChangeDeltaProcessor with changes made yesterday.
Dan, I've submitted your patch. It seems to resolve the original problem. However, I found another synchronization issue unrelated to your patch: - Create a new Model project - Create a class diagram - Create an entity in the diagram and add three methods and three attributes from the diagram. - Close the diagram - Expand entity in TS Explorer - Delete all attribute/methods EXCEPT the first attribute - Open diagram file. In some cases the diagram doesn't open properly due to an NPE because the diagram is not synced up properly. Created attachment 183176 [details]
327698_bug2_incomplete.txt
So I have pinpointed the issue, but I am not exactly sure how to solve it. The issue has to do with creating an attribute/method/literal using the buttons on the diagram (either from the tray or from the pop-up that shows up when hovering over an artifact) When using these buttons they create an extra xml element in the .wvd file of the diagram. Using the TS explorer context menu to add an attribute/method/literal does not do this, it seems to be EMF code that creates the xml element. As long as the diagram stays open when a delete happens the same eElement object that the attribute/method/literal was created on will be referenced and correctly deleted, but if the diagram is closed before deleting than the eElement object referenced is a different one, this seems to cause the failure to update the .wvd file by removing the xml element referring to the attribute/method/literal.
From what I understand I think the correct solution is to somehow not allow these xml elements to be added in the first place (might not be possible since so much is EMF code) or to somehow remove them either when the diagram is closed, or when the attribute/method/literal is deleted (I tried this but am getting an error saying my code must be in a transaction, something I know little about).
The xml elements don't seem to be needed for everything to work correctly. However, if an xml element exists and point to an attribute/method/literal that has been deleted than this is what causes the diagram to seem corrupt.
My patch so far currently only applies to attributes on an entity. It attempts to remove any of these unwanted xml tags when an updated closed diagram is saved. If someone can help get this working than I can implement the rest. When I try to run it I get an error saying it must be in a write transaction. This patch shows the whole file replaced, but the only thing changed is the saveDiagram method along with a few constants and imports.
So perhaps this is an EMF/GEF/GMF issue and could be referred to that team for comment on the additional XML. Created attachment 183511 [details]
327698_bug2_hack_patch.txt
Changed the saveDiagram() method in ClosedDiagramSynchronizerBase
This is really just a hack that possibly could be unstable. But I tested it a bit and couldn't uncover any issues. What it does is upon updating a saved diagram when it is saving it goes through and removes all 4th level xml children in the .wvd file. In all the playing around I did this seemed to just be methods, literals, and attributes. Like I say, this is very much a hack, but could be a temporary solution to save some headache from the diagram files getting out of sync.
I wonder if this might actually be a problem with tigerstripe model in o.e.t.workbench.ui.visualeditor/model Trying to open almost any of these files gives errors saying that an older version of the GMF model is loaded and that it needs to be migrated. ??? Anybody familiar with this? That could explain why the additional XML elements are being added. I suggest you ask Richard and or Eric re these files and if they need to be migrated. Created attachment 185293 [details] 327698 c7 patch https://bugs.eclipse.org/bugs/show_bug.cgi?id=327698#c7 issue fixed. "Additional xml" is GMF's notation model and it's used to store visual configuration. Closed diagrams synchrinized updates only semantic model of diagrams, so the notation model should be updated on diagram open. Patch attached. Anton's patch applied. We can finally put this beast to rest. Thanks a lot Anton!! |