Bug 436956

Comment 1 Ronan Bar 2014-06-09 07:50:31 EDT

Created attachment 244077 [details]
Sample Model

Comment 2 Toni Siljamäki 2014-06-09 08:52:50 EDT

This problem have been there for quite some time, and the save-close-open-model
activity that kicks in when having multiple linked models open is quite strange,
after modifying one of the models and saving it.

The problem seem to the same for both semantic model element references between
models and hyperlinks to diagrams in different models. Quite annoying...

Comment 3 Christian Damus 2014-06-09 11:47:36 EDT

This is exactly why the Model Explorer now presents the referenced models as editable in the context of the referencing model.  You only need to open one editor, for example the editor for ModelZ, and you can edit both ModelZ and ModelY in this editor.

However, any new diagrams created in ModelZ's editor for elements in ModelY are added to ModelZ's notation resource, not ModelY's, which is not good and is probably the #1 reason why it is still necessary sometimes to work with two editors.  But the problem with having multiple editors open is that they maintain separate editing domains and separate in-memory copies of all resources involved, so when ModelY's editor detects that the ModelZ has changed on disk, it needs to re-load ModelZ, which implies re-loading all of the dependencies in ModelY, which is effected by simply closing and re-opening the editor.  An unfortunate consequence of this is that, for example, the entire undo history is lost, in addition to editor tabs being out of order, selection/focus being changed, etc.

Comment 4 Toni Siljamäki 2014-06-09 14:47:43 EDT

Thanx Christian, but...

That's exactly how we cannot have it, because it's extreemely annoying.
A user may find it OK when working only on two models, or two fragments/parts,
but it doesn't scale, when model editors are auto-closed with a reorganized UI.

There is a very simple use case showing why it will not scale:
Bug 411574 -[Resource Update] Editor windows are collapsed into one when saving

Then imagine having multiple models/fragments/parts for a system function open,
and this "thing" begin to happen when editing one model referenced by others.

Your "#1 reason" mentioned in Comment 3 I can only agree to.
= You cannot sit in one place and hack around all over the place. :)
...and create diagrams ending up where you cannot expect them to end up.

In my use case, which architects have complained about, there are hyperlinks
to diagrams in different models/fragments/parts which have been setup to
simplify navigation between diagrams in a functional network hierarchy.

Different domain models have been opened in different editors, on my advice,
because they should never edit one domain model in the context of another.
(I have already spend a whole day repairing one such model after the Git repo
structure was altered, just to rescue one week of Papyrus work for one guy)

Then, when modifying a model having its diagrams referenced from other models,
this auto-closing-on-save begin... Imagine that you have arranged your UI
so that you view several model diagrams simultenously, like in Bug 411574.

The consequence of this, for the user, is that the entire UI setup is wrecked,
regarding open diagrams, disposition, focus, arrangement in multiple views etc.

This is, of course, not acceptable.

I'm glad Ronan detected this, because I have not yet had the time to create
and provide a reproducable test case for this very annoying behavior.

There is a REAL need to reload imported models if the already referenced
elements/diagrams are gone/lost, but you should only need to reload the stuff
that have changed in your currently open in-memory views of imported models,
in a true "lazy loading" fashion, which should happen silently.

"simply closing and re-opening the editor" is a workaround that does not scale.

Comment 5 Toni Siljamäki 2014-06-09 14:57:57 EDT

Some bugs on which this one depends: 366029, 290261, 411569, 411574

Comment 6 Ronan Bar 2014-06-10 03:16:13 EDT

To clarify some more:

This bug does not occur if only the diagram from ModelZ are open. If diagrams from ModelZ and ModelY are open then the context will be lost upon saving.

So yes I agree the goal is that the user is allowed do all their work on both models via the Model Explorer but we must support the user having many diagrams open from many models without context being lost upon save, or any other event. As you say Christian we often do not want to edit the ModelZ diagrams when working on ModelY specific stuff. Also note, as Papyrus does not support all modelling operations via the Model Explorer (for many different realtionship types like dependency relations) we must support this use-case.

Comment 7 Camille Letavernier 2014-06-10 04:03:50 EDT

I see different issues here. Some can be fixed easily, some require some important core changes which can only be provided in the next release (Too late for Luna SR0, and probably too dangerous for SR1, but this would require some more investigation and prototyping to confirm)

The source of the problem is that, unlike other tools or modelers such as Sphinx or Sirius (I think), Papyrus doesn't use a singleton EditingDomain/Resource set for the entire session. Instead, each Editor (In the Eclipse terminology) has its own EditingDomain/Resource set. This has several advantages and probably as many drawbacks. The first consequence is that libraries (and dependent models in general) are never shared, which requires some synchronization. When we fixed the synchronization mechanism in Kepler, we made some experiments to see whether it was possible to support resource unloading. At this time, it wasn't possible: there were a few bugs in EMF, and GMF doesn't natively support resource reloading. Papyrus doesn't properly support it either, and we often ended up with zombie objects.

So, we chose the safest solution: restart the editor, to ensure data consistency. After that, we tried to improve the usability a little bit, but these are essentially workarounds (Allowing the edition of imported libraries in the same editor/editing domain).

Now that the bugs in EMF are fixed, we can probably start thinking about a more scalable solution, i.e. proper resource reloading. As I see it:

- Resource reloading works fine. The cross-model references are properly updated by EMF
- Diagram editors need to be restarted: most (all?) GMF EditParts do not support proxy resolution
- Tables: To be investigated
- Other Papyrus components: anything which keeps a reference to an EObject needs to be fixed. In most cases, it will not check whether the EObject has been unloaded (Whereas it should)

In some cases, we also need a conflict-resolution mechanism: unless you save each change you make, conflicts will happen. The simplest "Conflict resolution" mechanism is to discard either change A or change B, but an EMF-compare-based solution would be best. CDO already provides a simple conflict-resolution mechanism, so it can probably be reused (and shared). The current implementation is basic (Discard change A or discard change B), but it can be improved later.

Another solution, which might be simpler than resource unloading, would be to share Editing Domains between editors: when opening a new editor, if another editor is already opened, you could have an option to share their edition context (This was the initial suggestion a couple of months ago, but this hasn't been implemented yet). However, this might add some confusion: sharing editing domains means sharing Operation History (Undo/Redo), Save actions, and Edit actions. That's a big change from the current philosophy.

Fixing the "Create diagram" actions to create diagrams in the proper resource, and adding an "Open in current editor" action to the project explorer might be less confusing and safer (But probably doesn't scale either, in terms of usability).

Comment 8 Patrik Nandorf 2014-06-13 03:03:27 EDT

From what I understand from this I'd prefer the current solution with several EditingDomains with synchronization that is. 

Sharing EditingDomains would, as Camille writes be an easier fix, but would likely confuse and annoy users with the shared Operation History

Comment 9 Christian Damus 2014-06-13 07:48:17 EDT

(In reply to Patrik Nandorf from comment #8)
> 
> Sharing EditingDomains would, as Camille writes be an easier fix, but would
> likely confuse and annoy users with the shared Operation History

The operation history needs not look like a single linear history shared amongst all editors.  If each editor has an IUndoContext that matches the resource it edits, and operations are tagged with contexts matching the resources that they modify (such as what the transaction editing domain already does automatically with ResourceUndoContext), then editors that work with unrelated/independent resources will have undo histories that appear to be separate.

With reference-counting of loaded resources to ensure that the last editor to be closed that was editing a resource unloads that resource on its way out the door, it could be a workable solution.  However, now that the Model Explorer shows all models loaded in the resource set, we would have to find a way to limit the scope of what it presents in each editor.  Likewise all of the reference-chooser dialogs, etc.  Overall, it could end up being rather complicated, but possibly worth thinking through ...

FTR, I would advocate either an editing domain per editor or a single domain shared by all editors.  I would discourage middle-ground solutions such as asking the user to choose which editors should share a domain or having the system automatically share domains amongst some editors and not others.

Comment 10 Patrik Nandorf 2014-06-13 07:54:32 EDT

(In reply to Christian W. Damus from comment #9)
> FTR, I would advocate either an editing domain per editor or a single domain
> shared by all editors.  I would discourage middle-ground solutions such as
> asking the user to choose which editors should share a domain or having the
> system automatically share domains amongst some editors and not others.

Agree

Comment 11 Camille Letavernier 2014-07-28 05:29:42 EDT

Bug 437217 has been completed, which solves this issue