Managing PCM Instances with CDO

Aus SDQ-Wiki

It is possible to manage and persist PCM instances with CDO using CDO's legacy model support. In order to support the full scope of features, including the retrieval of the change history for change delta analyses it is possible to generate the model code as a native CDO model. However, due to way EMF's code generator handles multi-inheritance it is not possible to do this as of now. In order to allow native model support, the genmodels of PCM have to be migrated to native CDO genmodels and the code has to be re-generated.

Migration Strategy

We updated Genmodels as follows:

  • "Feature Delegation": Dynamic

(default: None)

  • Added to "Model Plug-in Variables": CDO=org.eclipse.emf.cdo

(default: none)

  • "Root Extends Class": org.eclipse.emf.internal.cdo.CDOObjectImpl

(default: org.eclipse.emf.ecore.impl.MinimalEObjectImpl$Container)

  • "Root Extends Interface": org.eclipse.emf.cdo.CDOObject

(default: org.eclipse.emf.ecore.EObject)

Feature Delegation Option

Regarding the "Feature Delegation" option, we decided as follows:

None

We tried to generate with "None"; however, then resources could not be correctly loaded & stored anymore.

Reflective & Dynamic

"Reflective calls the generated accessors which call the dynamic accessors whereas Dynamic the generated accessors call the reflective accessors which call the dynamic accessors. The former is flexible if you override the generated accessors, the latter are more efficient when the reflective API is invoked directly, as is the case for most of the framework's use of the instances."

From: https://www.eclipse.org/forums/index.php/t/857261/

Virtual

Not tested.

Migrated Genmodels

Currently, we enabled full CDO support in genmodels for:

  • Identifier
  • Units
  • Probfunction
  • StoEx
  • PCM
  • Quality
  • MetricSpec
  • ExperimentAutomation
  • EDP2 (including MeasuringPoint and PCMMeasuringPoint)
  • MonitorRepository
  • ServiceLevelObjectives
  • Architectural Templates