0

Just getting started with ModeShape and I have a question, is it possible to change the nodeType definition (via: nodeTypeMgr.registerNodeTypes(File, true))?

Let's say I add a field to a noteType, I noticed that even after executing the method call above, calling setProperty() on an existing node (persisted when the old nodeType definition was in place) results in a ConstraintViolationException.

If the behavior is by design, would you delete the node and re-persist it again to fix it? Or is there an incantation that "updates" the node to the new definition?

I am using ModeShape 3.1.0.Final with JBossAS 7.1.1.Final.

Clement P
  • 3,243
  • 1
  • 19
  • 20

1 Answers1

2

ModeShape does allow you to change/update existing node types, and this may indeed make existing content "invalid" when making further changes. This is an area that the JSR-283 specification leaves a lot up to the implementation. For example, Section 19.2.4.1 "Updating Node Types" says this:

A repository that supports node type management may support updates to a node type already in use as the type of an existing node. The extent of any such capability is implementation dependent. For example, some implementations may permit only changes which do not invalidate existing content, while others may allow larger changes. How any resulting incompatibilities are resolved is also implementation dependent.

ModeShape does implement the more permissive changes, and so we recommend using good practices and procedures when updating node types. If you know you're adding a mandatory property definition or child node definition to a node type, then consider the implications before doing that and make sure you update the content (before or after the node type is changed, depending upon whether the node type might allow residual properties or residual child nodes).

If your node types do not have residual property definitions and/or child node definitions, then it may make sense to implement the change in multiple steps:

  1. Register the node type(s) first with non-mandatory (e.g., optional) property definition(s) and/or child node definition(s).
  2. Change any existing content that uses the node types and add the new property and/or child nodes, using navigation or queries to find the nodes that need to be changed.
  3. Register the node type(s) with the same property definition(s) and or child node definition(s) now being mandatory.

Or, if it makes sense in your repository, add the property definition(s) as a new mixin. After the mixin is registered, you can start using it on new content and you can go back and add the mixin to existing nodes where you want to add the new property (or properties).

We also recommend that you think about how your node types might evolve when you're first creating the node types. Evolution will just be one of several facets that influence your design.

The challenge of updating node types is that what needs to be done (and the best way to do it) depends so much upon the specifics of the node type. This is why we chose to leave a lot of this process up to you. The alternative would have been that ModeShape is far more restrictive on what kinds of updates are allowed on node types, and that would have prevented and/or constrained a lot of node type updates.

Randall Hauch
  • 7,069
  • 31
  • 28
  • so just to be sure, you have to delete an existing node and re-create it in order to have add a new (optional) property to a node, right? That's the only way I've seen it to work (or else it's always a CVE). Mix-ins are a good idea for managing node evolution down the line for sure. – Clement P Feb 12 '13 at 23:18
  • No, I never said you have to delete existing nodes before updating a node type. Rather, you can modify the node type that is used in the existing nodes, but depending upon how you change the node type this may make existing nodes no longer valid so that when you then edit the existing node, you may have to make additional changes so that the existing node satisfies the updated primary node type and mixin types. I also tried to explain how you might avoid this by using the 3-step process described above (none of which involve removing any nodes). – Randall Hauch Feb 13 '13 at 03:00
  • ic, perhaps I am not using the code properly then since I get a CVE when I add a property (optional) to an existing node (persisted when the node type does not have the property) after updating the node type via registerNodeType(). It simply tells me that the property does not exist. – Clement P Feb 13 '13 at 20:26
  • essentially, I cannot do step 2, I took your verb "Change" as removing the existing node and creating a new one in its place :) interestingly, I catch the CVE, delete the node and create a new one, persist it and it works – Clement P Feb 13 '13 at 20:27
  • Please report such problems in our forums at https://community.jboss.org/en/modeshape?view=discussions – Randall Hauch Feb 13 '13 at 21:44
  • The issue was found to be https://issues.jboss.org/browse/MODE-1821 rather than not being able to change existing nodes (it pointed me to think so because it seem to suggest a schema change as the culprit) – Clement P Feb 21 '13 at 06:09