Community
Participate
Working Groups
We have an automatic migration system for Sirius models (.aird and .odesign), which relies on an internal version number in the XMI files to decide which migration steps are required to "upgrade" models created with earlier versions of Sirius. Currently, it does not prevent loading models which are created by (or have been migrated to) more recent version of Sirius. The result is unpredictable and can lead to data corruption, with Sirius version X being unable to correctly interpret models created for version Y > X. For example, Sirius 2.0 will happily open a session on an aird file created with Sirius 3.0, even though the way the references to semantic models have completely changed between those versions (see #456351). The <semanticResources/> element used by Sirius 3.0 is ignored by Sirius 2.0, which expects a <models xmi:type="mm.Type" href="path/to/the/model.mm"/> reference. The resulting session is broken and can cause strange behaviors and lead to data loss or corruption. The migration system already has all the information to decide if the model being loaded is newer that the Sirius version being executed, and thus can not be interpreted correctly. The challenge is on how to react in this case, especially from the end-user's point of view: it should not appear as an error, but as a message that the end-user can understand and on which s/he can act.
To cancel session opening about this use case, a RuntimeException can be thrown during session opening, a OperationCancelException or a CoreException typically. In default Sirius UI, there are several means to open a session : - through a Modeling Project - through a simple aird resource. - at Eclipse restart with an opened editor - through a marker in Problems view For 2 first cases, session opening is done through OpenRepresentationsFileJob job. For 2 last cases, it is done through SessionEditorInput. OpenRepresentationsFileJob being a Job, if a session opening has been cancelled, a IStatus.ERROR is returned to inform end-user about the issue through ErrorDialog from Platform UI. Note that ErrorDialog appears only if Progress dialog is not displayed. For SessionEditorInput, a SessionEditorInput.status is used by opened editor to inform end-user that content can't be accessed, see Bug 480773. If another UI is used to open the session using SessionManager, it is the responsibility of the caller to react to RuntimeException or specifically to OperationCancelException to give UI feedback. To customize the way session opening cancel is displayed to end-user for the 2 first cases, Platform UI provide facility, see https://wiki.eclipse.org/Platform_UI_Error_Handling . And to leave mean to end-user to react to this message, by for example trying to reopen session ignoring the model/Sirius releases mismatch, we need a mean to give an option to session opening to ignore this model/Sirius releases mismatch. Bug 456326 has for goal to provide options at session opening.
There is also the case of resource reload, for example resource content has been replaced, outside Session, by content from a newer Sirius release. It is for that we manage migration in DescriptionResourceImpl.load()/AirDResourceImpl.load() in addition to their factories.
(In reply to Esteban DUGUEPEROUX from comment #2) > There is also the case of resource reload, for example resource content has > been replaced, outside Session, by content from a newer Sirius release. > It is for that we manage migration in > DescriptionResourceImpl.load()/AirDResourceImpl.load() in addition to their > factories. The only situation I see where this could be occuring would be two separate Eclipse instances, running different Sirius version, which share the same physical aird files. Otherwise as long as we are inside a single Eclipse instance, with a single Sirius version installed, I don't see a scenario where this could happen (but maybe I'm wrong). If the only case where this could happen is indeed when sharing the same physical files *at the same time*, I think we can simply document this restriction and live with it.
(In reply to Pierre-Charles David from comment #3) > (In reply to Esteban DUGUEPEROUX from comment #2) > > There is also the case of resource reload, for example resource content has > > been replaced, outside Session, by content from a newer Sirius release. > > It is for that we manage migration in > > DescriptionResourceImpl.load()/AirDResourceImpl.load() in addition to their > > factories. > > The only situation I see where this could be occuring would be two separate > Eclipse instances, running different Sirius version, which share the same > physical aird files. Otherwise as long as we are inside a single Eclipse > instance, with a single Sirius version installed, I don't see a scenario > where this could happen (but maybe I'm wrong). > > If the only case where this could happen is indeed when sharing the same > physical files *at the same time*, I think we can simply document this > restriction and live with it. There is also the case end-user simply copy paste an aird to replace one from opened session. Ok I will document this not supported cases.
Note that a StatusHandler, see https://wiki.eclipse.org/Platform_UI_Error_Handling , cannot be used because a single one for the whole product can be used and overriding the default one is too impacting for others non Sirius users.
Waiting the possibility to use a typical SiriusResourceVersionMismatchException.OPTION_IGNORE_VERSION_MISMATCH at session opening, a static variable would be used : SiriusResourceVersionMismatchException.ignoreVersionMismatch
(In reply to Esteban DUGUEPEROUX from comment #4) > (In reply to Pierre-Charles David from comment #3) > > I don't see a scenario > > where this could happen (but maybe I'm wrong). > > > > If the only case where this could happen is indeed when sharing the same > > physical files *at the same time*, I think we can simply document this > > restriction and live with it. > > There is also the case end-user simply copy paste an aird to replace one > from opened session. > Ok I will document this not supported cases. I had not thought of that case, but you're right. If it is possible to handle it without too much additional cost/complexity, we should try to handle it.
New Gerrit change created: https://git.eclipse.org/r/64846
New Gerrit change created: https://git.eclipse.org/r/64889
New Gerrit change created: https://git.eclipse.org/r/65086
Gerrit change https://git.eclipse.org/r/65086 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=69f8e50b6e9089a141883882c5e14312c0a40a81
New Gerrit change created: https://git.eclipse.org/r/71575
For testing purpose, consider the version mismatch for the following resource: - main aird - controlled aird - selected vsm scenarios to tests: - open project - restart eclipse with an editor in the memento - export representation from file - open vsm
Moving to 4.1, as it's too late the week before RC1 for such a change. Even though I don't see any obvious bug in the currently proposed patch, given the nature of the change almost any bug or unforeseen situation could make Sirius 4.0 completely broken, with sessions that refuse to open in some cases. The probablity of this happening seems low, but the impact *if* it happened is too big to take the risk. We'll try to merge this as soon as the maintenance branch for 4.0.x is done, so that we'll have as much time as possible to test this before 4.1.
For the validation note that the default user feedback when there is a representation mismatch does nothing. If there is a vsm or representation version mismatch, the session is automatically closed and an error is logged. Consider the case that allows loading the representation despite the version mismatch as tested with junit test ResourceVersionMismatchTest. Scenarios: * open a modeling project with representation version mismatch (just increment the aird version)-> you have a dialog box message and an error in log * open a modeling project with vsm version mismatch -> you have a dialog box message and an error in log * Launch eclipse with a VSP in the workspace containing a vsm with a more recent version. -> A warning should be logged indicating that this viewpoint has not be registered in the ViewpointRegistry
Gerrit change https://git.eclipse.org/r/64846 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=f6b6e2a9ba90f681639b027966545e7172ab7acd
New Gerrit change created: https://git.eclipse.org/r/76602
Gerrit change https://git.eclipse.org/r/76602 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=d5807d87855665f2c21e093cce23c466e00ab1c8
Available in Sirius 4.1.0, see https://wiki.eclipse.org/Sirius/4.1.0 for details.
