Interface IModelEvolutionSupport

DB store support for model evolution.

Model evolution support is responsible for evolving the models stored in a DB store to match the currently registered EPackages.

Model evolution support implementations are registered via factories contributing to the org.eclipse.emf.cdo.server.db.evolution.supports product group. Here is an example contribution in plugin.xml:

 <extension point="org.eclipse.net4j.util.factories">
    <annotationFactory
       productGroup="org.eclipse.emf.cdo.server.db.evolution.supports"
       type="phased"
       productClass="org.eclipse.emf.cdo.server.db.evolution.phased.PhasedModelEvolutionSupport"/>
 </extension>
 

If model evolution support is desired, an instance must be created and set on the DB store via setModelEvolutionSupport() before the store is activated by the IRepository. If the store is configured via the CDOServerApplication and the cdo-server.xml configuration file, this can be achieved by specifying the modelEvolutionSupport element as follows:

 <store type="db">
   ...
   <modelEvolutionSupport type="phased" rootFolder="@state/evolution" mode="migrate">
     <
     <changeDetector/>
     <repositoryExporter type="default" binary="false"/>
     <schemaMigrator/>
     <storeProcessor type="my-sql-processor" myExtraArg="data"/>
     <repositoryProcessor type="my-eobject-handler" myExtraArg="data"/> -->
     <listener type="log"/>
     <listener type="my-extra-checks"/>
   </modelEvolutionSupport>
   ...
 </store>
 

The optional mode attribute can be used to specify whether model evolution should be performed automatically (migrate), only prevented with an exception (prevent), or skipped entirely (disabled) when model changes are detected.

The optional listener elements specify additional model evolution listeners to be notified during model evolution. They can be used to implement logging, custom checks, or additional evolution steps.

Note that model evolution happens very late during the activation of a DB store, but very early during the activation of the IRepository. Therefore, phase handlers must not rely on any services of the repository. In particular, they must not access the repository's package registry because it is not yet available!