Best approach to update nodetypes hieararchy

[Martin Perez <mp...@gmail.com>]

Hi.

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?

Originally, I thought about unregister the original node definition and
register the new one, but unregister throws a not implemented message.
Anyways, I think that maybe this would not work as removing node definitions
could have other consequences.

So now, I'm thinking about adding new properties and nodes manually to old
legacy definitions. But, what should be the best approach?

Thanks,

Martin

Re: Best approach to update nodetypes hieararchy

[Martin Perez <mp...@gmail.com>]

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 <mp...@gmail.com> 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 <s....@inovex.de> 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 <bc...@osafoundation.org> wrote:
> > >
> > >>On 1/22/06, Martin Perez < mpermar@gmail.com> 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.
> > >>
> > >
> > >
> >
>
>

Re: Best approach to update nodetypes hieararchy

[Martin Perez <mp...@gmail.com>]

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 <bc...@osafoundation.org> wrote:
>
> On 1/22/06, Martin Perez <mp...@gmail.com> 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.
>

Re: Best approach to update nodetypes hieararchy

[Brian Moseley <bc...@osafoundation.org>]

On 1/22/06, Martin Perez <mp...@gmail.com> 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.