Migration to 1.7

Migration to JCR 1.7 from previous releases

The Migration is possible via export/import to/from XML files.

For exporting a node (tree) to the XML file (system view) apply the following to your eXo JCR 1.5.x repository (where destPath - it is a path to the creating file)

File destFile = new File(destPath);
 session.exportSystemView(source.getPath(), new FileOutputStream(destFile), false, false);
 outStream.close();

For importing a node (tree) from the XML file (system view) apply the following to your eXo JCR 1.6.1+ repository (where pathToFile - it is a path to the file containing JCR data)

File srcFile  = new File(pathToFile);
 /* import data */
 session.importXML (target.getPath(), new FileInputStream(destFile), ImportUUIDBehavior.IMPORT_UUID_COLLISION_THROW);
 /* save into persistent storage */
 session.save();

NOTE: such an import procedure won't work for the root node, so prepare several files for root's children and then import them one by one

More details are available at wiki http://wiki.exoplatform.org/xwiki/bin/view/JCR/How+to+JCR+import+export

Manual database migration

As a custom solution it's possible to update database manually with SQL-script. In version 1.7 auto-update option is disabled by default (update-storage='false' in workspace configuration). Storage changes which should be updated to 1.7 are relations between a database and an external values storage(s). 'id' attribute in value-storage configuration was added. This attribute is used instead of the absolute file path in values storage. The 'id' is stored in database table JCR_VALUES (JCR_MVALUES, JCR_SVALUES) column STORAGE_DESC. Before 1.7 it contained the absolute path of value storage file. Since 1.7 this field contains storage id. So, for a manual update you have to update your JCR_VALUES table column STORAGE_DESC with valid storage id, i.e. with value described in configuration. For example the workspace configuration has value-storage with id 'Storage #1'.

<value-storage id="Storage #1" class="org.exoplatform.services.jcr.impl.storage.value.fs.TreeFileValueStorage">
      <properties>
        <property name="path" value="/path/to/values/storage/workspace_name"/>
      </properties>
    .................

Then your script for single-db case will be the folowing:

UPDATE jcr_svalue SET storage_desc='Storage #1' WHERE storage_desc LIKE '/path/to/values/storage/workspace_name/%'

for multi-db

UPDATE jcr_mvalue SET storage_desc='Storage #1' WHERE storage_desc LIKE '/path/to/values/storage/workspace_name/%'

Notice, if you have more than one storage per workspace the script should be more detailed in the like-clause to touch only values located in the target workspace.

After the successful update you have to update the JCR_SCONTAINER table VERSION column.

UPDATE jcr_scontainer SET version='1.7'

for multi-db

UPDATE jcr_mcontainer SET version='1.7'

The migration is done.