Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Load model under alternative EMF metamodel
[CDO] Load model under alternative EMF metamodel [message #1739901] Fri, 05 August 2016 14:22 Go to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
Hi,

I have a model stored in a cdo repository under an EMF metamodel v1. Now I have since changed the model to create v2 - without changing the NsURI.

I have been trying to configure my session to load up the old model instance using the v1 version of the metamodel, but I have not been able to get this to work. Attempting to load directly results in a "Schema locked" execption (as you would expect at the metamodel has changed.) I have also tried pre-populating the session and view package registries with manually loaded models. However here I get the following exception;

java.lang.ArrayIndexOutOfBoundsException: 50
	at org.eclipse.emf.cdo.common.id.CDOIDUtil.read(CDOIDUtil.java:466)
	at org.eclipse.emf.cdo.spi.common.protocol.CDODataInputImpl.readCDOID(CDODataInputImpl.java:393)
....


when trying to load the resource.

I suspect either my packages are being confused with the originals, or it is trying to map the old model data into the generated code of the new model. Although I am not sure how to work out if either of these hypothesis are correct.

Prior to using CDO I was also to create a resource set with a self contained package registry and load a dynamic ecore instance up and migrate it to the new metamodel definition. I am hoping to be able to do the same thing with CDO.

Does anyone have any pointers on where to go from here?

Is it possible to force the creation of a dynamic ecore instance rather than map to generated code?

Is there some other mechanisms to control the package registry?

I have seen some references related to setting setGeneratedPackageEmulationEnabled to true to be able to generate the metamodels from the database. Does this need to be set to true when the database is created or does it work any time?

Thanks,

Simon
Re: [CDO] Load model under alternative EMF metamodel [message #1739978 is a reply to message #1739901] Sat, 06 August 2016 14:03 Go to previous messageGo to next message
Per Sterner is currently offline Per SternerFriend
Messages: 91
Registered: October 2011
Member
Simon Goodall wrote on Fri, 05 August 2016 16:22
Hi,

I have a model stored in a cdo repository under an EMF metamodel v1. Now I have since changed the model to create v2 - without changing the NsURI.


Why without changing the NsURI? The access to the old model would work with the option 'GeneratedPackageEmulationEnabled' and you could access the new model with the new/different NsURI. It should work directly.

(If the generated models aren't in the runtime and the flag 'GeneratedPackageEmulationEnabled' is used, you should be able to access two different CDO-Repositories where you have different Metamodels with the same NsURI, but you don't want to to have different metamodels with the same NsURI Smile, https://www.eclipse.org/forums/index.php?t=msg&th=477847&goto=1043426&#msg_1043426 )
Re: [CDO] Load model under alternative EMF metamodel [message #1740624 is a reply to message #1739978] Tue, 16 August 2016 12:20 Go to previous messageGo to next message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
Thanks. I've tried changing my code to use different nsURIs. However I get a new problem. CDO seems to have problems creating a dynamic instance when the super type is a generated abstract class. It fails with an invalid classifier exception.

I have created a small project (https://github.com/drsgoodall/cdo-test-1) to highlight this. I used oomph to install a neon based CDO workspace. The "MainClassTest" can be run as a JUnit-Plugin test.

There are two ecore models - base.ecore and example.ecore - both generated. There is also an example-v1.ecore which contains my previous example.ecore version used to build the embedded repository database.

When my object does not have a superclass I am able to load up the v1 model instance. However when the object extends the class in the base.ecore I get the exception.

Regards.

Simon
Re: [CDO] Load model under alternative EMF metamodel [message #1740679 is a reply to message #1740624] Wed, 17 August 2016 08:36 Go to previous message
Simon Goodall is currently offline Simon GoodallFriend
Messages: 35
Registered: July 2009
Member
I have resolved this issue - I need to manually populate the package registry and manually load in the base.ecore as well as the example-v1.ecore
Re: [CDO] Load model under alternative EMF metamodel [message #1741987 is a reply to message #1740624] Tue, 16 August 2016 13:39 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33133
Registered: July 2009
Senior Member
Simon,

It's a limitation of dynamic EMF models that it must be able to create
an instance of the non-dynamic super class because that instance is
what's used to emulate the dynamic extension.

So you have two choices. One, don't make this base class abstract. Two,
specialize the factory of this base class.

We did this, for example, for Oomph's Setup model. Here SetupTask
itself is abstract:

public abstract class SetupTaskImpl extends ModelElementImpl implements
SetupTask
{

But we need to be able to create dynamic instances of subclasses of it.

So we hand implemented a non-abstract subclass, i.e., just implement
stubs for any missing implementations:

public final class DynamicSetupTaskImpl extends SetupTaskImpl
{
public boolean isNeeded(SetupTaskContext context) throws Exception
{
return false;
}

public void perform(SetupTaskContext context) throws Exception
{
// Do nothing.
}
}

And in the SetupFactoryImpl we added this hand written method:

@Override
public EObject create(EClass eClass)
{
if (eClass == SetupPackage.Literals.SETUP_TASK)
{
return new DynamicSetupTaskImpl();
}

return createGen(eClass);
}

And used the "Gen" pattern on the original generated method:

/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* @generated
*/
public EObject createGen(EClass eClass)
{

So when the SetupFactory needs to create an instance of SetupTask, it
creates a DynamicSetupTaskImpl.


On 16.08.2016 14:20, Simon Goodall wrote:
> Thanks. I've tried changing my code to use different nsURIs. However I
> get a new problem. CDO seems to have problems creating a dynamic
> instance when the super type is a generated abstract class. It fails
> with an invalid classifier exception.
>
> I have created a small project
> (https://github.com/drsgoodall/cdo-test-1) to highlight this. I used
> oomph to install a neon based CDO workspace. The "MainClassTest" can
> be run as a JUnit-Plugin test.
>
> There are two ecore models - base.ecore and example.ecore - both
> generated. There is also an example-v1.ecore which contains my
> previous example.ecore version used to build the embedded repository
> database.
>
> When my object does not have a superclass I am able to load up the v1
> model instance. However when the object extends the class in the
> base.ecore I get the exception.
>
> Regards.
>
> Simon


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:[CDO] Is it possible to store generated EMF model directly to CDO?
Next Topic:check whether the model is loaded properly or not
Goto Forum:
  


Current Time: Tue Apr 16 06:03:18 GMT 2024

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

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

Back to the top