Autocreated child nodes

[clementp]

I have a question about the JCR specification.

For a node definition that contains a child node with a default type that is autocreated, if a new field is added to a previous saved node without the child node, should modeshape automatically create the child node right away when it encounters the old version?

Basically let's say a node is defined as

[test:nodeA]
- fieldA (STRING)

and it's saved at /testnode

If we then update the definition of nodeA to:

[test:nodeA]
- fieldA (STRING)
+ childNode (nt:unstructured) = nt:unstructured autocreated

On subsequent access of the childNode, i.e. session.getNode("/testNode/childNode"), should the implementation assume that a node should be created immediately with the type nt:unstructured?

Essentially, I am trying to avoid the need to call

Node node = session.getNode("/testNode");
if (!node.hasNode("childNode")) {
     node.addNode("childNode");
}

even though autocreated is specified. It would be a nice to have for sure to have modeshape automatically execute the given routine if it knows that it's possible for the node to be autocreated on the fly.

If it's a good idea, I'll file a feature request (and maybe give it a try myself).

[rhauch]

The JCR specification talks about autocreated properties and child nodes in Section 3.7.2.3:

An item may be declared auto-created, meaning that it is automatically created upon creation of its parent node.

and then in 3.7.2.3.1:

If an item is auto-created but not protected then it must be immediately created in transient space when its parent node is created. Creation of auto-created non- protected items must never be delayed until save (see §10.11 Saving).

ModeShape follows this behavior when nodes are created. But in your case the node types are modified after the node is created, and I don't think the specification really addresses this case at all. ModeShape does not look for auto-created properties or child nodes upon save, simply because of the overhead (and because it's not address).

However, I'm open to suggestions for how we might address this. One option is to do the extra work on Session.save() that would affect everyone. Another option is to add a ModeShape-specific method (via our public API) that would re-validate a given node when the application wanted to use it.

Thoughts?

[clementp]

I guess I am most interested in making sure that node definitions can evolve with time without having to add boiler-plate code to deal with data migrations. I guess in this particular case, it can be argued that when creating nodes/properties below the auto-created child node that the system should respect the autocreated tag and automatically create the necessary node and/or when reading the autocreated child/property that the system should auto-create those too. I think both needs to be there for the system to allow node definitions to change without having to ask the user to do anything in particular to existing data. I am not sure whether the idea of "reading causing writes" would be a good idea though, perhaps the read would simply create pseudo nodes/properties that would only be persisted if need be (e.g. when the property or node is actually changed and a save() occurs).