Home » Modeling » EMF » ECore model evolution and versioning
ECore model evolution and versioning [message #1796752] |
Thu, 18 October 2018 13:11 |
Ewoud Werkman Messages: 28 Registered: January 2018 |
Junior Member |
|
|
Hi all,
We are developing a Ecore model that is under heavy development. In the mean time we've developed several tools around this model, such as a Sirius-based editor, and services that e.g. generate instances from raw data. Many of the services are using an XSD that is generated from the model's GenModel.
To keep track of the different versions of the model, we version the namespace URI. With every release we update the version number.
However, now our tooling is extending and the number of instances is growing, updating the namespace URI's in all the files becomes a burden. Especially Sirius' AIRD-files are quite problematic as they contain numerous references to the namespace (compared to just 'updating' the xmlns:ns='xxx' of an model instance).
How can we deal with this issue?
I've opted to get rid of the version number in the namespace, saving us from updating all the files when there are minor changes to the model, but then there is no version information available at all in the files, which I don't like. I know XSD's can be versioned with a version-attribute, but this seems not supported by EMF.
Any ideas? Thanks!
|
|
| |
Re: ECore model evolution and versioning [message #1796805 is a reply to message #1796760] |
Fri, 19 October 2018 06:29 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
Changing the nsURI is of course a reasonable way to version the model; this way the version is recorded/reflected in the instances. But of course the very fact its recorded in the instances also becomes a burden given you'd like the tools to be able to read older versions as well as the latest version. One approach to support that is to literally keep around the older versions as dynamic models such that older instances can be processed according to the older model version as dynamic instances that can then be automatically transformed into the latest generated version of the model. Depending on how much the structure of the model changes, that can be relatively straight forward. It's still a relatively complex process to manage and of course if you have resources that literally use the model itself (the diagrams, the genmodel), those are things that need to be maintained and versioned like the models themselves...
Indeed an XML Schema has a version attribute and Ecore does not. But Ecore also has annotations so you could easily use an EAnnotation to add a version-like attribute to the EPackage.
Note that an exceedingly useful load/save option in this type of scenario (and evolving model) is XMLResource.OPTION_RECORD_UNKNOWN_FEATURE. If you avoid making "binary incompatible" changes to the model, e.g., don't rename things, don't delete things, it will always be the case that newer tools can read older serializations. With the OPTION_RECORD_UNKNOWN_FEATURE option, it will also be the case that older tools can read newer serializations. The information which isn't recognized (doesn't conform to the model), is simply recorded as "raw" XML in the XMLResource.getEObjectToExtensionMap and that information is written back out again on save, so an older tool doesn't lose the newer information. I mention this because this recorded information can also be post processed directly after loading such that a newer tool can transform information from binary incompatible changes to conform to the newer model. Also, the org.eclipse.emf.ecore.xmi.XMLResource.OPTION_EXTENDED_META_DATA can be used to help automatically transform renamed classes and features.
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| |
Re: ECore model evolution and versioning [message #1796862 is a reply to message #1796858] |
Sat, 20 October 2018 03:07 |
Ed Merks Messages: 33216 Registered: July 2009 |
Senior Member |
|
|
1. Yes, an EAnnotation can be used to record arbitrary information. E.g., on an EPackage use New Child -> EAnnotation. In the latest release, several choices will be offered here because there is built-in knowledge about some special annotation that are recognized by the framework. Use the Properties view to set the source URI, e.g., model:/version and on the new EAnnotation use New Child -> Details Entry to define an entry, e.g., version="1.0". Of course how you structure the annotation is arbitrary and up to you. Just keep in mind that this information is generated into the Javadoc (of the package interface in this case), and is available in the generated model, so you could use EcoreUtil.getAnnotation(XyzPackage.eINSTANCE, "model/version", "version") to get this information at runtime.
2. You can add load/save hooks using org.eclipse.emf.ecore.xmi.XMLResource.OPTION_RESOURCE_HANDLER so in that handler's postLoad you could process the contents of getEObjectToExtensionMap, which maps each loaded object to the associated arbitrary XML represented by AnyType instances. This article has useful information related to this: https://www.theserverside.com/news/1364302/Binding-XML-to-Java
3. I think each EAnnotation is mapped to XML Schema annotation. At runtime you can use EcoreUtil.getAnnotation( "eObject.eClass.getEPackage(),"model/version", "version) to get the instance's model version. Note that with this approach the serialized instance does not have version information
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
| | | | |
Goto Forum:
Current Time: Wed Sep 18 19:44:10 GMT 2024
Powered by FUDForum. Page generated in 0.04834 seconds
|