Skip to content
Snippets Groups Projects
  • Simon Barner's avatar
    4143f522
    Problem description: · 4143f522
    Simon Barner authored
    - By default, EMF uses fragment-path based links to persist EReferences. While this works fine for standalone model resources, it can cause inconsistencies in case there are multiple resource models that contain cross-resource references. (I.e., if the structure of the AF3 model resource changes, the links from the external model resource can become invalid)
    - The recommended way to work around this is to configure EMF to use IDs to encode EReferences.
    
    Solution:
    - Change persistence of AF3 model resources to encode references using an (extrinsic) xmi:id, that is identical to the model element's org.fortiss.tooling.kernel.model.IIdLabled.id. A dedicated XMIResource type for AF3 model resources is used (which is created by a resource factory registered for *.af3_23 files)
    - The reason for not using IIdLabled.id as intrinsic ID is that the implemented solution using xmi:id is both forward and backward compatible
    - At the price of losing forward compatibility, the IIdLabled.id could be changed to a derived, volatile EAttribute that simply returns the value of xmi:id
    - Add EContentAdapter to sync xmi:id and IIdLabled.id
    - Ensure uniqueness of IDs (that is now much more crucial) during when loading and saving as well as importing and exporting models (and print a warning to the console in case duplicates have been detected and fixed)
    - As an additional safety layer, add constraint checkers to ensure uniqueness of IDs and consistency of IIdLabled.id and xmi:id
    
    Related changes:
    - Speed up loading and saving of XMI resources by setting corresponding XMLResource options
    - Ensure that IDs are assigned to annotations as soon as they are instantiated
    refs 2309
    4143f522
    History
    Problem description:
    Simon Barner authored
    - By default, EMF uses fragment-path based links to persist EReferences. While this works fine for standalone model resources, it can cause inconsistencies in case there are multiple resource models that contain cross-resource references. (I.e., if the structure of the AF3 model resource changes, the links from the external model resource can become invalid)
    - The recommended way to work around this is to configure EMF to use IDs to encode EReferences.
    
    Solution:
    - Change persistence of AF3 model resources to encode references using an (extrinsic) xmi:id, that is identical to the model element's org.fortiss.tooling.kernel.model.IIdLabled.id. A dedicated XMIResource type for AF3 model resources is used (which is created by a resource factory registered for *.af3_23 files)
    - The reason for not using IIdLabled.id as intrinsic ID is that the implemented solution using xmi:id is both forward and backward compatible
    - At the price of losing forward compatibility, the IIdLabled.id could be changed to a derived, volatile EAttribute that simply returns the value of xmi:id
    - Add EContentAdapter to sync xmi:id and IIdLabled.id
    - Ensure uniqueness of IDs (that is now much more crucial) during when loading and saving as well as importing and exporting models (and print a warning to the console in case duplicates have been detected and fixed)
    - As an additional safety layer, add constraint checkers to ensure uniqueness of IDs and consistency of IIdLabled.id and xmi:id
    
    Related changes:
    - Speed up loading and saving of XMI resources by setting corresponding XMLResource options
    - Ensure that IDs are assigned to annotations as soon as they are instantiated
    refs 2309