Migrate existing meta-models to CDO Native

This document will help you to migrate existing models to CDO Native mode.

1. Migrate existing meta-models to CDO Native
   1. CDO Native vs CDO Legacy mode
   2. Create a CDO-native gen-model from scratch
   3. Convert an existing gen-model to CDO Native
   4. Meta-model constraints
      1. Transient references must be properly derived
      2. EClasses with identical names
      3. Support of Generic Types
   5. EMF generated editors constraints

CDO Native vs CDO Legacy mode

By default, the code generated for a meta-model is generic and does not have any strong dependency to CDO. In this case, CDO relies on a Legacy mode to support collaboration above such models.

However, in order to gain in performance and scaleability, you should modify your gen-models to make the generated code rely on CDO (we talk about CDO Native meta-models).

Create a CDO-native gen-model from scratch

Righ-click on your metamodel (ECore) file and select New > Other... > EMF Generator Model . Press Next and select Ecore model (CDO Native) in the Select a Model Importer page.

Convert an existing gen-model to CDO Native

Modify your gen-model or create a copy of it if you want to keep your previous gen-model. If you choose to copy an existing gen-model and if it references other gen-models, modify these references to reference cdo-native gen-models.

• Set the Model Plug-in Variables property to CDO=org.eclipse.emf.cdo
• Set the Root Extends Class property to org.eclipse.emf.internal.cdo.CDOObjectImpl
• Set the Root Extends Interface property to org.eclipse.emf.cdo.CDOObject
• Set the Feature Delegation property to :
  • Dynamic if you have derived features and want your getters to be called
  • Reflective if you do not have any derived feature. The generated getters will not be called by eGet() method.

Meta-model constraints

Transient references must be properly derived

As a transient reference is not persistent, it has to be properly derived in order to be able to calculate its result each time. This algorithm must be based on non transient feature. At a given instant, every connected (non dirty) clients must have the same result for this transient and derived reference. Otherwise, refresh on each clients will produce a difference, the session will be dirty and the lock will be taken in loop.

Finally, a transient feature must be derived for this calculating equivalence among clients.

EClasses with identical names

It is possible to have the same name for 2 EClasses in different packages or metamodels. However, the following property must be added in the server configuration, in the store/mappingStrategy section:
<property name="qualifiedNames" value="true"/>

This will make all database tables prefixed with the qualified EPackage name, and hence allow your database to support EClasses with the same name.

Support of Generic Types

CDO does not support metamodels containing EClasses parameterized with Generics yet.

EMF generated editors constraints

As with a shared modeling project, it is possible to open a shared semantic resource with associated EMF generated editor by double click, it is necessary to have generated code with EMF 2.7 to avoid a ClassCastException at the beginning of XXXEditor.createModel() or replace the two first instruction at the beginning of XXXEditor.createModel() by URI resourceURI = EditUIUtil.getURI(getEditorInput());.