Yes, I also planned to create a migration tool, but for complex migrations only.
I'm doing tests with a very simple operation : add a mandatory child property definition to a node type definition. It's really simple, but currently I'm not able to do it. I think, that such type of operations would have been easy to manage from Jackrabbit. At least, it could be added a parameter to the method telling if we want to maintain repository integrity so, if we mark that parameter as false it would be the developer responsability to ensure repository integrity. Another question comes to my mind, if that property was not mandatory, then the operation would fit on the "trivial" changes that reregister/unregister methods control? Martin On 1/22/06, Brian Moseley <[EMAIL PROTECTED]> wrote: > > On 1/22/06, Martin Perez <[EMAIL PROTECTED]> wrote: > > > Currently, I have a defined nodetype hiearchy, and deployed an > application > > with that hierarchy. Now, I find that this hierarchy will change on next > > version, so I need to update legacy repository node types. This update > can > > mean adding node child defintions, adding properties to node > definitions, > > etc... > > > > So, what is the best approach to solve this problem? > > i have a similar issue. ideally we'd be able to issue ddl-style > commands to the repository to have structural changes made for us, but > the jcr specification doesn't allow for it. > > my current plan is to build a migration tool that copies data from a > repository with the old structure to a fresh one with the new > structure. that way i can roll back to the old repository (and version > of my application) if something goes wrong with the migration. >
