Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » CDO & Model Evolution
CDO & Model Evolution [message #1043317] Wed, 17 April 2013 14:51 Go to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
Hi,

I am looking at using CDO in my application as a way to created a shared
model repository. However a key issue is the ability to handle changes
to meta-models. I am hoping to find out whether or not our current
approach would work with CDO or if there are things we could do
differently that would make it feasible.

Our metamodels (we have several which are used in a single model
instance) are given a combined version number (e.g. 1, 2, 3, 4, etc).
When a set of changes to any of the metamodels have been completed we
increment this number (i.e. 1 becomes 2). Our model instance data is
stored alongside the version number is was last saved against. When we
attempt to load a model, we compare this stored version number against
the latest version number - and if required determine the number of
steps required to get from version a to version b before loading it
against the current meta-model version.

We store each version of the metamodel in the same plugin as the current
latest version with the version appended. For example if the current
version is 3, we would see mymodel.ecore (the latest version),
mymodel-v1.ecore and mymodel-v2.ecore. For each step (v1 to v2) we then
programatically load up the appropriate metamodel versions and the data
model instance, perform the required changes then save under the next
version number. This is repeated until we get to the latest vesion. I
should note, all the metamodels have the same namespace URI - this does
not change between versions.


Can this approach work with CDO? I have seen one post that said
metamodels cannot change once loaded into a CDO repository.

Regards,

Simon Goodall
Re: CDO & Model Evolution [message #1043426 is a reply to message #1043317] Wed, 17 April 2013 17:40 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 17.04.2013 16:51, schrieb Simon Goodall:
> Hi,
>
> I am looking at using CDO in my application as a way to created a shared model repository. However a key issue is the
> ability to handle changes to meta-models. I am hoping to find out whether or not our current approach would work with
> CDO or if there are things we could do differently that would make it feasible.
>
> Our metamodels (we have several which are used in a single model instance) are given a combined version number (e.g.
> 1, 2, 3, 4, etc). When a set of changes to any of the metamodels have been completed we increment this number (i.e. 1
> becomes 2). Our model instance data is stored alongside the version number is was last saved against. When we attempt
> to load a model, we compare this stored version number against the latest version number - and if required determine
> the number of steps required to get from version a to version b before loading it against the current meta-model version.
>
> We store each version of the metamodel in the same plugin as the current latest version with the version appended. For
> example if the current version is 3, we would see mymodel.ecore (the latest version), mymodel-v1.ecore and
> mymodel-v2.ecore. For each step (v1 to v2) we then programatically load up the appropriate metamodel versions and the
> data model instance, perform the required changes then save under the next version number. This is repeated until we
> get to the latest vesion. I should note, all the metamodels have the same namespace URI - this does not change between
> versions.
And the version is stored where, if not in the nsURI? I think it's problematic to have/use different models with the
same nsURI. The nsURI is generally used to uniquely identify the model, no matter when or where it's looked up.

>
>
> Can this approach work with CDO? I have seen one post that said metamodels cannot change once loaded into a CDO
> repository.
CDO does not yet support automatic instance migration after model evolution. But when we add this functionality we will
probably require different nsURIs for different models.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: CDO & Model Evolution [message #1043431 is a reply to message #1043426] Wed, 17 April 2013 17:49 Go to previous messageGo to next message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
Hi Simon,

depending on your requirements, EMFStore
(http://www.eclipse.org/emfstore), another model repository for EMF,
might be a fit. If you use it in its default config, it will store your
models in XMI files which can be migrated by Edapt
(http://www.eclipse.org/edapt/). There is even an integration plugin to
integrate Edapt into EMFStore.

Cheers,
Maximilian


Am 17.04.2013 19:40, schrieb Eike Stepper:
> Am 17.04.2013 16:51, schrieb Simon Goodall:
>> Hi,
>>
>> I am looking at using CDO in my application as a way to created a
>> shared model repository. However a key issue is the ability to handle
>> changes to meta-models. I am hoping to find out whether or not our
>> current approach would work with CDO or if there are things we could
>> do differently that would make it feasible.
>>
>> Our metamodels (we have several which are used in a single model
>> instance) are given a combined version number (e.g. 1, 2, 3, 4, etc).
>> When a set of changes to any of the metamodels have been completed we
>> increment this number (i.e. 1 becomes 2). Our model instance data is
>> stored alongside the version number is was last saved against. When we
>> attempt to load a model, we compare this stored version number against
>> the latest version number - and if required determine the number of
>> steps required to get from version a to version b before loading it
>> against the current meta-model version.
>>
>> We store each version of the metamodel in the same plugin as the
>> current latest version with the version appended. For example if the
>> current version is 3, we would see mymodel.ecore (the latest version),
>> mymodel-v1.ecore and mymodel-v2.ecore. For each step (v1 to v2) we
>> then programatically load up the appropriate metamodel versions and
>> the data model instance, perform the required changes then save under
>> the next version number. This is repeated until we get to the latest
>> vesion. I should note, all the metamodels have the same namespace URI
>> - this does not change between versions.
> And the version is stored where, if not in the nsURI? I think it's
> problematic to have/use different models with the same nsURI. The nsURI
> is generally used to uniquely identify the model, no matter when or
> where it's looked up.
>
>>
>>
>> Can this approach work with CDO? I have seen one post that said
>> metamodels cannot change once loaded into a CDO repository.
> CDO does not yet support automatic instance migration after model
> evolution. But when we add this functionality we will probably require
> different nsURIs for different models.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Re: CDO & Model Evolution [message #1043516 is a reply to message #1043431] Wed, 17 April 2013 20:20 Go to previous messageGo to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
Hi Maximilian,

We have looked at using edapt, but it does not work in our case - a core
set of shared metamodels and separate per application metamodel
extensions. As I understand it the change history cannot be shared
unless all metamodels are considered at once.

But perhaps EMF Store is worth a look. Do you think it would work with
my proposed alternative migration scheme?

Regards,

Simon


On 17/04/2013 18:49, Maximilian Koegel wrote:
> Hi Simon,
>
> depending on your requirements, EMFStore
> (http://www.eclipse.org/emfstore), another model repository for EMF,
> might be a fit. If you use it in its default config, it will store your
> models in XMI files which can be migrated by Edapt
> (http://www.eclipse.org/edapt/). There is even an integration plugin to
> integrate Edapt into EMFStore.
>
> Cheers,
> Maximilian
>
>
> Am 17.04.2013 19:40, schrieb Eike Stepper:
>> Am 17.04.2013 16:51, schrieb Simon Goodall:
>>> Hi,
>>>
>>> I am looking at using CDO in my application as a way to created a
>>> shared model repository. However a key issue is the ability to handle
>>> changes to meta-models. I am hoping to find out whether or not our
>>> current approach would work with CDO or if there are things we could
>>> do differently that would make it feasible.
>>>
>>> Our metamodels (we have several which are used in a single model
>>> instance) are given a combined version number (e.g. 1, 2, 3, 4, etc).
>>> When a set of changes to any of the metamodels have been completed we
>>> increment this number (i.e. 1 becomes 2). Our model instance data is
>>> stored alongside the version number is was last saved against. When we
>>> attempt to load a model, we compare this stored version number against
>>> the latest version number - and if required determine the number of
>>> steps required to get from version a to version b before loading it
>>> against the current meta-model version.
>>>
>>> We store each version of the metamodel in the same plugin as the
>>> current latest version with the version appended. For example if the
>>> current version is 3, we would see mymodel.ecore (the latest version),
>>> mymodel-v1.ecore and mymodel-v2.ecore. For each step (v1 to v2) we
>>> then programatically load up the appropriate metamodel versions and
>>> the data model instance, perform the required changes then save under
>>> the next version number. This is repeated until we get to the latest
>>> vesion. I should note, all the metamodels have the same namespace URI
>>> - this does not change between versions.
>> And the version is stored where, if not in the nsURI? I think it's
>> problematic to have/use different models with the same nsURI. The nsURI
>> is generally used to uniquely identify the model, no matter when or
>> where it's looked up.
>>
>>>
>>>
>>> Can this approach work with CDO? I have seen one post that said
>>> metamodels cannot change once loaded into a CDO repository.
>> CDO does not yet support automatic instance migration after model
>> evolution. But when we add this functionality we will probably require
>> different nsURIs for different models.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
>
Re: CDO & Model Evolution [message #1043527 is a reply to message #1043426] Wed, 17 April 2013 20:42 Go to previous messageGo to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
On 17/04/2013 18:40, Eike Stepper wrote:
> Am 17.04.2013 16:51, schrieb Simon Goodall:
>> Hi,
>>
>> I am looking at using CDO in my application as a way to created a
>> shared model repository. However a key issue is the ability to handle
>> changes to meta-models. I am hoping to find out whether or not our
>> current approach would work with CDO or if there are things we could
>> do differently that would make it feasible.
>>
>> Our metamodels (we have several which are used in a single model
>> instance) are given a combined version number (e.g. 1, 2, 3, 4, etc).
>> When a set of changes to any of the metamodels have been completed we
>> increment this number (i.e. 1 becomes 2). Our model instance data is
>> stored alongside the version number is was last saved against. When we
>> attempt to load a model, we compare this stored version number against
>> the latest version number - and if required determine the number of
>> steps required to get from version a to version b before loading it
>> against the current meta-model version.
>>
>> We store each version of the metamodel in the same plugin as the
>> current latest version with the version appended. For example if the
>> current version is 3, we would see mymodel.ecore (the latest version),
>> mymodel-v1.ecore and mymodel-v2.ecore. For each step (v1 to v2) we
>> then programatically load up the appropriate metamodel versions and
>> the data model instance, perform the required changes then save under
>> the next version number. This is repeated until we get to the latest
>> vesion. I should note, all the metamodels have the same namespace URI
>> - this does not change between versions.
> And the version is stored where, if not in the nsURI? I think it's
> problematic to have/use different models with the same nsURI. The nsURI
> is generally used to uniquely identify the model, no matter when or
> where it's looked up.

The version is managed outside of EMF - we maintain a separate version
number as described corresponding to a set of metamodels. There is only
one version of a metamodel (the latest revision) registered in the
global registry. We create local, temporary registry instances during
migration with the older revisions.

We have not changed the nsURI to make it easier to load and save the
existing model instances during migration and also to keep maintenance
of EMF Validation simple - here constraints are registered against the
nsURI. However these are more convenience than absolute requirements.

>
>>
>>
>> Can this approach work with CDO? I have seen one post that said
>> metamodels cannot change once loaded into a CDO repository.
> CDO does not yet support automatic instance migration after model
> evolution. But when we add this functionality we will probably require
> different nsURIs for different models.

My plan is to keep the migration process outside of CDO (at least for
now), perhaps as a single mass upgrade operation. I am trying to
understand what can and cannot be done with CDO around my approach. If I
were to switch out the standard XMI resource set with the CDO resource
set (+ other model generation requirements) what issues would arise? It
sounds like the nsURI might well be an issue.

Are there any other ways to handle migration? Edapt is not an option for
us as we have application specific metamodels extending a common set of
meta-models and this does not appear compatible with the history
tracking elements of edapt.

Thanks,

Simon

>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: CDO & Model Evolution [message #1043773 is a reply to message #1043527] Thu, 18 April 2013 05:31 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 17.04.2013 22:42, schrieb Simon Goodall:
> On 17/04/2013 18:40, Eike Stepper wrote:
>> Am 17.04.2013 16:51, schrieb Simon Goodall:
>>> [...] I should note, all the metamodels have the same namespace URI
>>> - this does not change between versions.
>> And the version is stored where, if not in the nsURI? I think it's
>> problematic to have/use different models with the same nsURI. The nsURI
>> is generally used to uniquely identify the model, no matter when or
>> where it's looked up.
>
> The version is managed outside of EMF - we maintain a separate version number as described corresponding to a set of
> metamodels. There is only one version of a metamodel (the latest revision) registered in the global registry. We
> create local, temporary registry instances during migration with the older revisions.
>
> We have not changed the nsURI to make it easier to load and save the existing model instances during migration and
> also to keep maintenance of EMF Validation simple - here constraints are registered against the nsURI. However these
> are more convenience than absolute requirements.
I see.

>
>>
>>>
>>>
>>> Can this approach work with CDO? I have seen one post that said
>>> metamodels cannot change once loaded into a CDO repository.
>> CDO does not yet support automatic instance migration after model
>> evolution. But when we add this functionality we will probably require
>> different nsURIs for different models.
>
> My plan is to keep the migration process outside of CDO (at least for now), perhaps as a single mass upgrade
> operation. I am trying to understand what can and cannot be done with CDO around my approach. If I were to switch out
> the standard XMI resource set with the CDO resource set (+ other model generation requirements) what issues would
> arise? It sounds like the nsURI might well be an issue.
In the absence of an "in situ" mechanism to migrate instances to new model versions you can use the CDOServerExporter,
transform the resulting XML file to the new model and then use CDOServerImporter to create a new repository from the
transformed data.

Just the other day Erdal pointed out that an xml/xquery database (for example, http://basex.org) would do a good job.

With this export + transform + import approach I see no issues regarding the usage of the same nsURI for different model
structures.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: CDO & Model Evolution [message #1043965 is a reply to message #1043773] Thu, 18 April 2013 10:18 Go to previous messageGo to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
On 18/04/2013 06:31, Eike Stepper wrote:
> Am 17.04.2013 22:42, schrieb Simon Goodall:
>> On 17/04/2013 18:40, Eike Stepper wrote:
>>> Am 17.04.2013 16:51, schrieb Simon Goodall:
>>>> [...] I should note, all the metamodels have the same namespace URI
>>>> - this does not change between versions.
>>> And the version is stored where, if not in the nsURI? I think it's
>>> problematic to have/use different models with the same nsURI. The nsURI
>>> is generally used to uniquely identify the model, no matter when or
>>> where it's looked up.
>>
>> The version is managed outside of EMF - we maintain a separate version
>> number as described corresponding to a set of metamodels. There is
>> only one version of a metamodel (the latest revision) registered in
>> the global registry. We create local, temporary registry instances
>> during migration with the older revisions.
>>
>> We have not changed the nsURI to make it easier to load and save the
>> existing model instances during migration and also to keep maintenance
>> of EMF Validation simple - here constraints are registered against the
>> nsURI. However these are more convenience than absolute requirements.
> I see.
>
>>
>>>
>>>>
>>>>
>>>> Can this approach work with CDO? I have seen one post that said
>>>> metamodels cannot change once loaded into a CDO repository.
>>> CDO does not yet support automatic instance migration after model
>>> evolution. But when we add this functionality we will probably require
>>> different nsURIs for different models.
>>
>> My plan is to keep the migration process outside of CDO (at least for
>> now), perhaps as a single mass upgrade operation. I am trying to
>> understand what can and cannot be done with CDO around my approach. If
>> I were to switch out the standard XMI resource set with the CDO
>> resource set (+ other model generation requirements) what issues would
>> arise? It sounds like the nsURI might well be an issue.
> In the absence of an "in situ" mechanism to migrate instances to new
> model versions you can use the CDOServerExporter, transform the
> resulting XML file to the new model and then use CDOServerImporter to
> create a new repository from the transformed data.
>
> Just the other day Erdal pointed out that an xml/xquery database (for
> example, http://basex.org) would do a good job.
>
> With this export + transform + import approach I see no issues regarding
> the usage of the same nsURI for different model structures.
>

I assume this would tie the migration process directly to the CDO db format?

One thought I have is to use multiple repository versions. For example,
connect to "repository_v1" and migration all the data into
"repository_v2". Although I assume any revision history will be lost
this way.

Regards,

Simon

> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: CDO & Model Evolution [message #1043991 is a reply to message #1043965] Thu, 18 April 2013 11:03 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6682
Registered: July 2009
Senior Member
Am 18.04.2013 12:18, schrieb Simon Goodall:
> [...] I assume this would tie the migration process directly to the CDO db format?
No, but to the XML export format, which itself is backend-independent.

>
> One thought I have is to use multiple repository versions. For example, connect to "repository_v1" and migration all
> the data into "repository_v2". Although I assume any revision history will be lost this way.
Yes.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: CDO & Model Evolution [message #1044726 is a reply to message #1043516] Fri, 19 April 2013 08:48 Go to previous message
Maximilian Koegel is currently offline Maximilian KoegelFriend
Messages: 253
Registered: July 2009
Senior Member
Hi Simon,

> We have looked at using edapt, but it does not work in our case - a core
> set of shared metamodels and separate per application metamodel
> extensions. As I understand it the change history cannot be shared
> unless all metamodels are considered at once.
If you want to evolve multiple meta-models they need to share one
history. Is this what you refer to?

> But perhaps EMF Store is worth a look. Do you think it would work with
> my proposed alternative migration scheme?
I know that we had users of EMFStore with a version number stored
outside of the URI. Anyway EMFStore migration is build on Edapt, so it
will not work for you if Edapt does not work for you, as you indicated
above. So we should first make sure Edapt would work for you.
BTW: We are in the process of graduation (1.0 release) with EMFStore
first RC is available: http://emfstore.org

Cheers,
Maximilian

>
> Regards,
>
> Simon
>
>
> On 17/04/2013 18:49, Maximilian Koegel wrote:
>> Hi Simon,
>>
>> depending on your requirements, EMFStore
>> (http://www.eclipse.org/emfstore), another model repository for EMF,
>> might be a fit. If you use it in its default config, it will store your
>> models in XMI files which can be migrated by Edapt
>> (http://www.eclipse.org/edapt/). There is even an integration plugin to
>> integrate Edapt into EMFStore.
>>
>> Cheers,
>> Maximilian
>>
>>
>> Am 17.04.2013 19:40, schrieb Eike Stepper:
>>> Am 17.04.2013 16:51, schrieb Simon Goodall:
>>>> Hi,
>>>>
>>>> I am looking at using CDO in my application as a way to created a
>>>> shared model repository. However a key issue is the ability to handle
>>>> changes to meta-models. I am hoping to find out whether or not our
>>>> current approach would work with CDO or if there are things we could
>>>> do differently that would make it feasible.
>>>>
>>>> Our metamodels (we have several which are used in a single model
>>>> instance) are given a combined version number (e.g. 1, 2, 3, 4, etc).
>>>> When a set of changes to any of the metamodels have been completed we
>>>> increment this number (i.e. 1 becomes 2). Our model instance data is
>>>> stored alongside the version number is was last saved against. When we
>>>> attempt to load a model, we compare this stored version number against
>>>> the latest version number - and if required determine the number of
>>>> steps required to get from version a to version b before loading it
>>>> against the current meta-model version.
>>>>
>>>> We store each version of the metamodel in the same plugin as the
>>>> current latest version with the version appended. For example if the
>>>> current version is 3, we would see mymodel.ecore (the latest version),
>>>> mymodel-v1.ecore and mymodel-v2.ecore. For each step (v1 to v2) we
>>>> then programatically load up the appropriate metamodel versions and
>>>> the data model instance, perform the required changes then save under
>>>> the next version number. This is repeated until we get to the latest
>>>> vesion. I should note, all the metamodels have the same namespace URI
>>>> - this does not change between versions.
>>> And the version is stored where, if not in the nsURI? I think it's
>>> problematic to have/use different models with the same nsURI. The nsURI
>>> is generally used to uniquely identify the model, no matter when or
>>> where it's looked up.
>>>
>>>>
>>>>
>>>> Can this approach work with CDO? I have seen one post that said
>>>> metamodels cannot change once loaded into a CDO repository.
>>> CDO does not yet support automatic instance migration after model
>>> evolution. But when we add this functionality we will probably require
>>> different nsURIs for different models.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>
>>
>


--
Maximilian Kögel

Get Professional Eclipse Support: http://eclipsesource.com/munich
Previous Topic:FSM/CPN pros and cons
Next Topic:[Teneo] @Columns annotation does not work
Goto Forum:
  


Current Time: Tue Mar 19 09:47:01 GMT 2024

Powered by FUDForum. Page generated in 0.03062 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top