| [CDO] Load model under alternative EMF metamodel [message #1739901] |
Fri, 05 August 2016 10:22  |
Eclipse User |
|
|
|
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 #1741987 is a reply to message #1740624] |
Tue, 16 August 2016 09:39  |
| Eclipse User |
|
|
|
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
|
|
|
Powered by
FUDForum. Page generated in 0.04251 seconds
Home
,