CDO in Collaborative Mode
This document will help you to migrate existing models to CDO Native mode.
1. 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. See Activate Legacy mode support.
However, in order to gain in performance and scalability, you should modify your gen-models to make the generated code rely on CDO (we talk about CDO Native meta-models).
The usage of CDO Native meta-models is required in production.
There is no warantee in Legacy mode. It comes with several drawbacks regarding scalability and stability. Though, it can be enabled if you want to test an existing tooling based on EMF and Sirius or simply start and discover collaborative features without the constraint to generate CDO Native model in a first step.
1.1. Activate Legacy mode support
Nevertheless, if you decide to use the Legacy mode, we encourage you to set the non-UI preference CDOSiriusPreferenceKeys.PREF_SUPPORT_LEGACY_MODE to true. It will solve some legacy mode issues. There is no guarantee that this preference will solve other potential issues.
1.2. Activate Legacy model detection
Sometimes it is complex to determine if all cdo native meta-models are generated, and you may want to detect such cases. The preference CDOSiriusPreferenceKeys.PREF_LEGACY_MODEL_DETECTION is used to activate the detection. When creating a shared modeling project or other connection wizards, if CDOSiriusPreferenceKeys.PREF_SUPPORT_LEGACY_MODE=false, CDOSiriusPreferenceKeys.PREF_LEGACY_MODEL_DETECTION=true and if there is at least a legacy model (not CDO Native) among semantic models, then,
-
a warning pop up is displayed,
-
a warning is logged which indicates the concerned EPackage of the legacy meta-models,
-
the session is closed.
By default, the preference value is false, that is the detection is disabled. Nevertheless, you may override its default value.
1.3. Setting the default preference value
You can follow the steps below to initialize this preference without providing a plug-in to do it. To do so, we will use pluginCustomization
-
In the .ini file, add the line -pluginCustomization path/from/EclipseExecutable/to/myPreferenceInitFile.ini before vmargs argument.
-
myPreferenceInitFile.ini is a property file. Add
<plugin_name>/<preference_name>=<value>
. For example,fr.obeo.dsl.viewpoint.collab/PREF_SUPPORT_LEGACY_MODE=true
2. Migrate existing meta-models to CDO Native
2.1. 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.
2.2. 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 properties 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 byeGet()
method.
-
-
Set Packages Suffixes > Implementation to
cdo.impl
instead ofimpl
on each GenPackages and nestedGenPackages to avoid generating CDO implementations with the same qualified name as legacy implementations. -
Set an empty string to Templates & Merge > Plugin Key to avoid generating extension points
org.eclipse.emf.ecore.generated_packaged
andorg.eclipse.emf.ecore.extension_parser
. -
Set the
Model Name
of each GenModel to*-CDONative
, e.g.Diagram-CDONative
. -
Add the
org.eclipse.emf.ecore.factory_override
extension inplugin.xml
with the factory of the model.
2.3. Meta-model constraints
2.3.1. 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) client must have the same result for this transient and derived reference. Otherwise, refresh on each client 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.
2.3.2. 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.
2.3.3. Support of Generic Types
CDO does not support metamodels containing EClasses parameterized with Generics yet.
2.4. EMF-generated editor 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 instructions at the beginning of XXXEditor.createModel()
by URI resourceURI = EditUIUtil.getURI(getEditorInput());
.
3. CDO R20191029-1629 – by Obeo
This version of CDO 4.7 is provided by Obeo. It brings several forks with fixes not yet included in the official CDO repository.
The official CDO 4.7.0 release is available here.
Forks provided by Obeo:
-
Bugzilla 352977 Change visibility of CDOTransactionImpl.collapseSavepoints() (org.eclipse.emf.cdo)
-
Bugzilla 389173 Adapter not notified on model change during invalidation (org.eclipse.emf.cdo)
-
Bugzilla 392720 Add workaround waiting true support of EMF Proxy in CDO (org.eclipse.emf.cdo)
-
Bugzilla 502067 org.eclipse.emf.cdo.server, org.eclipse.net4j.util Update UserManager to allow customization
-
Bugzilla 502065 Addition of an exception in case the users file is not found. (org.eclipse.net4j.util)
-
Bugzilla 506514 Avoid failures on inconsistent states in CDOSavepoint (org.eclipse.emf.cdo)
-
Bugzilla 458349 Revert addition of XMLResource in CDOResource interface implementations (org.eclipse.emf.cdo)
-
Bugzilla 420607 Avoid CDOPermission.NONE on SecurityPackage.Literals.USER_PASSWORD feature to be able to upload a security model. (org.eclipse.emf.cdo.server.security)
-
Bugzilla 400311 Avoid touch modifications making transaction dirty (org.eclipse.emf.cdo)
-
Bugzilla 458349 Remove @Override annotation in DawnWrapper addition of XMLResource (org.eclipse.emf.cdo.dawn)
-
Bugzilla 538089 Decode the resource URI before computing the applicability of ResourcePermission (org.eclipse.emf.cdo.security)
-
Bugzilla 538239 Fix SSL Mode (org.eclipse.emf.cdo)
-
Bugzilla 539021 Fix bug in LockStatePrefetcher (org.eclipse.emf.cdo)
-
Bugzilla 552512 Deactivate Session after CDOServerExporter execution