Community
Participate
Working Groups
Created attachment 282015 [details] ecore based model Model managed by two sessions were inconsistent after several undo operations ------------------------------------------------------ I attach I ecore based model to reproduce the issue with screehshoots about the starting state and the result after undoing modification In the capture validModel.png it is the starting state of my models. In the capture invalidModel.png is the resulting state after doing the steps described below. To reproduce : - Open ecore1 session - Open ecore1 class diagram - Open ecore2 session - Open ecore2 class diagram - Go to ecore1 class diagram - Add a new Class and save the session - Go to ecore2 class diagram - Add double Attribute de D class and save the session - do 4 CTRL-Z and save the session The ecore1 is modified by deleting a newly created class and by deleting names of the classes. This is a general problem. It is reproduce-able on any model managed by two sessions.
I forget to add that I encontred cases where all elements created in the first resource (ecore1 on the test case) were deleted
Hi Faycal, From which session do you do the undo ? From the attached invalidModel.png, I assume that you made the undos from session1. Please note that: - the save of ecore1 class diagram (session1) triggers a reload of this resource in session2 - the operation histories and command stacks are specific for each session. - the model ecore1 is managed/loaded in two different transactional editing domain, a change in the workspace (save) triggers a reload of the model in the other session, with no info on the atomic changes/steps on each model element. Regards,
Created attachment 282093 [details] Command
Hi Maxim, I do the undo from the Session2. The undo/redo mechanism is shared according to the org.eclipse.core.commands.operations.OperationHistoryFactory#getOperationHistory() which is a singleton. I think, the Resource Synchronizer (org.eclipse.sirius.business.internal.session.danalysis.SessionResourcesSynchronizer) of the session2 add an operation to the shared stack when it detects that the resource of the session 1 is modified. I the capture I added, shows the command responsible of putting the ecore1 into inconsistent state. I think it is the recording command created in the Resource Synchronizer. Regards,
(In reply to Faycal Abka from comment #4) > Hi Maxim, > > I do the undo from the Session2. > > The undo/redo mechanism is shared according to the > org.eclipse.core.commands.operations. > OperationHistoryFactory#getOperationHistory() which is a singleton. > > I think, the Resource Synchronizer > (org.eclipse.sirius.business.internal.session.danalysis. > SessionResourcesSynchronizer) of the session2 add an operation to the shared > stack when it detects that the resource of the session 1 is modified. > > I the capture I added, shows the command responsible of putting the ecore1 > into inconsistent state. I think it is the recording command created in the > Resource Synchronizer. > > Regards, Sorry for the typo. Maxime
Hi Faycal, Your are right, the operation history is a singleton, but each Sirius session has its own undo context. The issue might come from the reload ; identity of elements is changed and undo might not be correctly managed. Sirius might need to flush the command stack/forbid undo when a reload is done.
Thank you Maxime. keep me aware for the resolution of this issue. Regards,
Hi Faycal, The issue has been reproduced. Thanks for the details and reproduction scenario. Please note, that it has not been added to a future release yet. Regards,
