Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Date: Wed, 4 Jul 2007 13:21:08 -0400 (Eastern Daylight Time)
From: Steven Singer <Steven.Singer@radintl.com>
To: users@jackrabbit.apache.org
Subject: Migrating versioned repositories
Message-ID: <Pine.WNT.4.63.0707041252020.2256@RAD212.main.radintl.corp>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


I am looking for some advice on dealing with changes to the structure of 
data in a repository that is versioned.

For example if you have an application that is storing a nt:versionable 
node in a JCR repository with a "name" property.   Your application allows 
the end user to browse historical versions of a node through some 
interface.

Now if in version 2 of your application you decide to change your node 
(and application) structure to have "first name" and "last name" 
properties instead of name.  Writing a migration program to alter the 
current version of the node seems straightforward, but what can you do 
about historical versions?

As I understand things, you can not change the contents of a historical 
version.

Three options come to mind

1. Write a program that connects to the v1 repository and for each node 
creates a new node in a second v2 repository, starting at the base version 
and going forward through the version history.  You can apply your 
filtering before commiting each node version.  Some of the JCR maintained 
version related attributes will be wrong but you will end up with a 
repository that allows the application to view old node versions.

Are there any tools or sample code to assist in making a node-by-node copy 
of a repository?

2. Use exportsysview ot export the repository as xml, use XSLT or 
something similar to filter the data and re-import it.  It is unclear to 
me if you can use the xml exports with versioning.  If I try to import a 
the repository with importxml I get "cannnot add a child to a protected 
node".

3. Not use JCR versioning but instead keep track of old versions of a node 
manually in a separate workspace. If I want to change the NodeType 
definitions between versions this approach on its own won't fix my 
problem.

Does anyone have any experience with any of these three options that they 
can share?  What is considered a Jackrabbit best practice? What works, 
what doesn't?

FYI, we are running Jackrabbit 1.0.1 (magnolia) but I think the situation 
would remain the same once we move to 1.3


Steven Singer
RAD International Ltd.
905-624-1888 ext 215


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to which they are
addressed.  If you have received this email in error please notify the
system manager.  Please note that any views or opinions presented in this
email are solely those of the author and do not necessarily represent
those of the company.  Finally, the recipient should check this email and
any attachments for the presence of viruses.  The company accepts no
liability for any damage caused by any virus transmitted by this email.