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
