Is it possible in Jackrabbit to restrict same name name siblings, without fully defining the types of my nodes? I am looking (I guess) for a simple CND definition that I can apply to my repository and use as the type of all of my nodes.
I am trying to follow the guidelines here: (http://wiki.apache.org/jackrabbit/DavidsModel), specifically, #1 avoiding creating a strong schema up-front, but I find this to be incompatible with #4, avoiding same name siblings.
I can manually avoid same name siblings, by locking the relevant parent node (collection), and checking for a node with the same name manually, and I will probably do this anyway in order to present application level error messages, but I'd prefer an additional layer of protection against inconsistency.
Also, I found this document:
http://www.day.com/specs/jcr/1.0/4.3.2_Support_for_Same_Name_Siblings_is_Optional.html
Though there is a required set of node types that every compliant repository must support, none of these required node types allow same-name siblings and any further node types available in a particular repository are implementation-specific. Therefore, it is possible for a repository to disallow same-name siblings altogether by restricting the set of available node types.
This seems inconsistent with what I have observed, e.g.:
final Repository repository = new TransientRepository();
final Session session = repository.login(new SimpleCredentials("username", "password".toCharArray()));
final Node collection = session.getRootNode().addNode("collection", "nt:unstructured");
final Node childA = collection.addNode("child", "nt:unstructured");
final Node childB = collection.addNode("child", "nt:unstructured");
session.save();
System.err.println(collection.getNodes("child").getSize());
//prints 2
Is this something that's changed in version 2.0 of JCR? (I notice that is a v1.0 specification)
I find JCR seems very appropriate in principle, but the lack of documentation is letting it down for me at the moment, so any links to good up-to-date information would be highly appreciated.