Home » Modeling » EMF » Model Evolution: Mixing of generated and dynamic models
| Model Evolution: Mixing of generated and dynamic models [message #1060145] |
Thu, 23 May 2013 10:20  |
 Sebastian Fuchs
Messages: 97
Registered: July 2009 |
Member |
|
|
Hello,
I am the developer of a civil engineering platform, consisting of some
common ecore base models and a lot of independent ecore application
models depending on the base models.
I fail to create incremental updates to handle some specific model
evolutions. Model evolutions may consist of any change like adding,
removing, renaming attributes, references or classes. Details below.
For every ecore model (base or application) I have generated code only
for the latest version. The version is reflected by a prefix of the
certain model's nsURI. Older versions of ecore models are provided only
dynamically via their *.ecore files.
So I am able to load any serialized application instance file of every
version, even older ones by emf onboard mechanism. The content and
version are identified via content type indentifiers.
To provide usage of an older version application instance, I must update
that instnace to the latest version. To avoid rewriting of every updater
each time a model evolves, I decided to make incremental updates, e.g.:
Latest version is 3.0, loaded instance has 1.0 - I update the instance
from 1.0 to 2.0 and from 2.0 to 3.0.
As there is (and will be) only generated code for the latest version,
every statement in the updater is generic to be future safe.
As stated in
http://wiki.eclipse.org/EMF/Recipes#Recipe:_Copying_models_from_an_EPackage_implementation_to_another_one
I use a modified Copier for updating. In principle, it provides a map
from source package nsURI to target package nsURI from where target
EClassifiers and EStructuralFeatures are determined.
So long everything works fine.
My problem is that in some cases - namely the updating to NOT the latest
version - I have a mixture of generated and dynamic instances. This is
due to the independent evolution of the application models and their
depending base models, mainly when the application instance can only be
loaded dynamically - as there is no generated code which then
(correctly) refers to the ecore-package of the base model instead of the
registered generated-package of the base model.
E.g. there could be
(Legacy) BaseV1.ecore, (Latest) BaseV2.ecore + *.java (where the
generated package is registered)
and
(Legacy) AppV1.ecore, (Legacy) AppV2.ecore, (Latest) AppV3.ecore +
*.java (where the generated package is registered)
where AppV1 depends on Basev1 and AppV2 + Appv3 depends on Basev2.
In such a case standard factories seem to create some generated
instances of the base model's classes.
Though I already worked around the resolution of the correct EStructural
Features as well as different generic access of EEnums in such a case, I
sometimes end in an ArrayStoreException:
java.lang.ArrayStoreException: org.eclipse.emf.ecore.impl.DynamicEObjectImpl
at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:124)
at org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:424)
at
org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:331)
at
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:315)
at org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307)
at
de.tragwerk.solution.statics.combination.model.update.Copier200To210.copyContainment(Copier200To210.java:112)
I think my problem is related to the following post:
http://www.eclipse.org/forums/index.php/mv/msg/173614/552576/
Though I am still not sure whether this is a bug.
If not, how can I force emf to only work with dynamic instances only for
the update scenario, which meens to maintain the original package
registries for all other standard use cases ?
Ore is there any other way to go ?
Thanks in advance
Sebastian
--
Dipl.-Ing. Sebastian Fuchs
TragWerk Software
Döking + Purtak GbR
Prellerstraße 9
01309 Dresden
Tel. +49 (0)351-433 08 50
Fax +49 (0)351-433 08 55
Email: sf@xxxxxxxx
http://www.tragwerk-software.de
http://www.twsolution.de
|
|
| |
| Re: Model Evolution: Mixing of generated and dynamic models [message #1060259 is a reply to message #1060145] |
Thu, 23 May 2013 17:17  |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Comments below.
On 23/05/2013 12:21 PM, Sebastian Fuchs wrote:
> Hello,
>
> I am the developer of a civil engineering platform, consisting of some
> common ecore base models and a lot of independent ecore application
> models depending on the base models.
>
> I fail to create incremental updates to handle some specific model
> evolutions. Model evolutions may consist of any change like adding,
> removing, renaming attributes, references or classes. Details below.
>
> For every ecore model (base or application) I have generated code only
> for the latest version. The version is reflected by a prefix of the
> certain model's nsURI. Older versions of ecore models are provided
> only dynamically via their *.ecore files.
>
> So I am able to load any serialized application instance file of every
> version, even older ones by emf onboard mechanism. The content and
> version are identified via content type indentifiers.
>
> To provide usage of an older version application instance, I must
> update that instnace to the latest version. To avoid rewriting of
> every updater each time a model evolves, I decided to make incremental
> updates, e.g.: Latest version is 3.0, loaded instance has 1.0 - I
> update the instance from 1.0 to 2.0 and from 2.0 to 3.0.
> As there is (and will be) only generated code for the latest version,
> every statement in the updater is generic to be future safe.
>
> As stated in
> http://wiki.eclipse.org/EMF/Recipes#Recipe:_Copying_models_from_an_EPackage_implementation_to_another_one
>
> I use a modified Copier for updating. In principle, it provides a map
> from source package nsURI to target package nsURI from where target
> EClassifiers and EStructuralFeatures are determined.
>
> So long everything works fine.
>
> My problem is that in some cases - namely the updating to NOT the
> latest version - I have a mixture of generated and dynamic instances.
> This is due to the independent evolution of the application models and
> their depending base models, mainly when the application instance can
> only be loaded dynamically - as there is no generated code which then
> (correctly) refers to the ecore-package of the base model instead of
> the registered generated-package of the base model.
> E.g. there could be
> (Legacy) BaseV1.ecore, (Latest) BaseV2.ecore + *.java (where the
> generated package is registered)
> and
> (Legacy) AppV1.ecore, (Legacy) AppV2.ecore, (Latest) AppV3.ecore +
> *.java (where the generated package is registered)
> where AppV1 depends on Basev1 and AppV2 + Appv3 depends on Basev2.
>
> In such a case standard factories seem to create some generated
> instances of the base model's classes.
So AppV2 would end up using generated base classes from BaseV2...
> Though I already worked around the resolution of the correct
> EStructural Features as well as different generic access of EEnums in
> such a case, I sometimes end in an ArrayStoreException:
>
> java.lang.ArrayStoreException:
> org.eclipse.emf.ecore.impl.DynamicEObjectImpl
> at org.eclipse.emf.common.util.BasicEList.assign(BasicEList.java:124)
> at
> org.eclipse.emf.common.util.BasicEList.addUnique(BasicEList.java:424)
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.doAddUnique(NotifyingListImpl.java:331)
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUnique(NotifyingListImpl.java:315)
> at
> org.eclipse.emf.common.util.AbstractEList.add(AbstractEList.java:307)
> at
> de.tragwerk.solution.statics.combination.model.update.Copier200To210.copyContainment(Copier200To210.java:112)
>
>
> I think my problem is related to the following post:
> http://www.eclipse.org/forums/index.php/mv/msg/173614/552576/
>
> Though I am still not sure whether this is a bug.
> If not, how can I force emf to only work with dynamic instances only
> for the update scenario, which meens to maintain the original package
> registries for all other standard use cases ?
You could register dynamic models in the resource set's registry, e.g.,
to load AppV2 using a dynamic version of BaseV2 (if you have one).
>
> Ore is there any other way to go ?
I terms of your follow-up comment, I imagine it could be problematic
that you end up using a generated version of BaseV2 when loading AppV2
instances because the AppV2 model itself (via super classes and feature
types) refers to a dynamic version of BaseV2 and anything created for
that (will not be compatible with the generated version of BaseV2). So
in general, you'd want to be sure that the dynamic versions are all
registered for the nsURIs in the resource set's package registry.
>
> Thanks in advance
> Sebastian
>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: Model Evolution: Mixing of generated and dynamic models [message #1060334 is a reply to message #1060259] |
Fri, 24 May 2013 07:59 |
Sebastian Fuchs
Messages: 97
Registered: July 2009 |
Member |
|
|
Thanks for the comment.
I forgot to mention that all dynamic legacy model packages are already
registered, as well as the generated latest model packages.
As the problem is solved, the following question is just a for my
understanding:
If I registered the dynamic version of BaseV2 package, wouldn't it
overwrite the registration of the generated package as they share the
identical nsURI ?
If so, I assume I would have to load the AppV2 instance twice:
1. with the unmodified ResultSet to determine the content and version
(would be possible to be an AppV3 model which must use generated
packages of BaseV2)
2. if it is a legacy instance - e.g. AppV2 - i have to modify the
resource set's package registry by replacing BaseV2 as described by you
and load it again.
Sebastian
Am 23.05.2013 19:17, schrieb Ed Merks:
>> Though I am still not sure whether this is a bug.
>> If not, how can I force emf to only work with dynamic instances only
>> for the update scenario, which meens to maintain the original package
>> registries for all other standard use cases ?
> You could register dynamic models in the resource set's registry, e.g.,
> to load AppV2 using a dynamic version of BaseV2 (if you have one).
>>
>> Ore is there any other way to go ?
> I terms of your follow-up comment, I imagine it could be problematic
> that you end up using a generated version of BaseV2 when loading AppV2
> instances because the AppV2 model itself (via super classes and feature
> types) refers to a dynamic version of BaseV2 and anything created for
> that (will not be compatible with the generated version of BaseV2). So
> in general, you'd want to be sure that the dynamic versions are all
> registered for the nsURIs in the resource set's package registry.
>>
>> Thanks in advance
>> Sebastian
>>
>>
>
|
|
|
| Re: Model Evolution: Mixing of generated and dynamic models [message #1060346 is a reply to message #1060334] |
Fri, 24 May 2013 08:44 |
Ed Merks
Messages: 33133
Registered: July 2009 |
Senior Member |
|
|
Sebastian,
Comment
On 24/05/2013 9:59 AM, Sebastian Fuchs wrote:
> Thanks for the comment.
>
> I forgot to mention that all dynamic legacy model packages are already
> registered, as well as the generated latest model packages.
>
> As the problem is solved, the following question is just a for my
> understanding:
>
> If I registered the dynamic version of BaseV2 package, wouldn't it
> overwrite the registration of the generated package as they share the
> identical nsURI ?
Yes, you shouldn't register both statically via the plugin.xml; you'll
see messages in the error log if you do that...
> If so, I assume I would have to load the AppV2 instance twice:
> 1. with the unmodified ResultSet to determine the content and version
> (would be possible to be an AppV3 model which must use generated
> packages of BaseV2)
EMF's content type determination effectively just does "raw XML parsing"
to determine the namespace of the root element... I.e., in
org.eclipse.emf.ecore.xmi.impl.RootXMLContentHandlerImpl.contentDescription(URI,
InputStream, Map<?, ?>, Map<Object, Object>)
> 2. if it is a legacy instance - e.g. AppV2 - i have to modify the
> resource set's package registry by replacing BaseV2 as described by
> you and load it again.
Ideally, for good performance, you do that before loading the resource
the first time, but that's a bit easier said than done: the resource
factory creating the resource doesn't know which resource set it's
creating the resource for... The deserializer does call
org.eclipse.emf.ecore.resource.impl.ResourceImpl.getURIConverter() to
get the URI converter, so you could specialize that method to ensure
that the appropriate registrations are in place for the type of content
that particular resource will be used to parse...
>
> Sebastian
>
>
>
> Am 23.05.2013 19:17, schrieb Ed Merks:
>
>>> Though I am still not sure whether this is a bug.
>>> If not, how can I force emf to only work with dynamic instances only
>>> for the update scenario, which meens to maintain the original package
>>> registries for all other standard use cases ?
>> You could register dynamic models in the resource set's registry, e.g.,
>> to load AppV2 using a dynamic version of BaseV2 (if you have one).
>>>
>>> Ore is there any other way to go ?
>> I terms of your follow-up comment, I imagine it could be problematic
>> that you end up using a generated version of BaseV2 when loading AppV2
>> instances because the AppV2 model itself (via super classes and feature
>> types) refers to a dynamic version of BaseV2 and anything created for
>> that (will not be compatible with the generated version of BaseV2). So
>> in general, you'd want to be sure that the dynamic versions are all
>> registered for the nsURIs in the resource set's package registry.
>>>
>>> Thanks in advance
>>> Sebastian
>>>
>>>
>>
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Tue Apr 16 06:43:25 GMT 2024
Powered by FUDForum. Page generated in 0.16978 seconds |
] 
Search
Help
Register
Login
Home
