jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berry van Halderen <b.vanhalde...@1hippo.com>
Subject Improving the reregistering of node types
Date Thu, 26 Aug 2010 09:47:51 GMT
Dear all,

In Jackrabbit, only "trivial" nodetype changes are supported(see
o.a.j.c.nodetype.NodeTypeDefDiff) to reregister node types.  In order to
change nodetypes we're currently using a module that can basically change any
nodetype structure.  However this is based on pure jcr interaction and
therefor requires relative expensive copy actions.

Better performance could be achieved if a broader set of changes could be
supported by reregistering node types, such as adding mandatory fields or
renaming a field.  By supplying a visitor or default pattern a user
application could control how the changes would be carried out.  Even though
some visiting might be necessary in these cases, because it would not require
jcr interaction, it could be executed much faster.

Alternatively a better support of Node.setPrimaryNodeType would also solve
this.  But that also cannot handle renamed, and blindly drops subnodes and
properties.  Especially for a structure of nodes, where both parent and child
nodes require a setPrimaryNodeType I can't see this to work at the moment.

What we like to probe over the list, is what the inside crowd response would
be to extend the reregistering or setPrimaryNodeType functionality such that a
broader set of operations can be supported, with a better performance than a
pure JCR module as we have now.

Naturally you would all be worried about the amount of work involved, but if
we could contribute most of this, would such an addition seen as valuable and
accepted.  Or is this just a path that you don't like JackRabbit see moving
to.  I can see quite a few obstacles on the way of realizing some of the
changes required, but what do you think would be most problematic to take?

With kind regards,
Berry van Halderen
Hippo

Mime
View raw message