Finally I got a solution approach: 1 - Tag the property as non-mandatory, even if the property is a mandatory one. 2 - In legacy repositories, reregister the node definition and add that property as non-mandatory and ensure manually integrity. 3 - In new repositories, add the property as mandatory.
Is not very ideal, but it works. At least I don't have to force my users to use a migration tool. Martin On 1/23/06, Martin Perez <[EMAIL PROTECTED]> wrote: > > Hi Sandro. > > Yes I tried it, but with the same result. It seems that my operation is > not tagged in jackrabbit as trivial (even as I think is a really trivial > one) and it throws a Not yet implemented message. > > Martin > > On 1/23/06, Sandro Böhme <[EMAIL PROTECTED]> wrote: > > > > Hello Martin, > > > > have you tried reregister(NodeTypeDef)? > > > > Regards, > > > > sandro > > > > Martin Perez wrote: > > > 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. > > >> > > > > > > > > > >
