Hi, On 11/6/07, Dan Diephouse <[EMAIL PROTECTED]> wrote: > Jukka Zitting wrote: > > There's an added benefit if you plan to use the "resource name" as a > > primary identifier for the entries, as you'll then be able to use > > normal path resolution instead of a more expensive query to retrieve > > an entry. > > Cool.
One caveat though, the names you use must then be valid JCR names, not just any strings. As a workaround you can use some encoding if you need to reliably use externally generated names as JCR names. Also, note that Jackrabbit currently starts hitting performance issues if you store too many (>> 1k) child nodes under a single parent. A typical workaround to this issue is to split the child nodes into a subtree based on the first few characters of the child node name. > Another question though - which node type do I use to disallow same name > siblings? I'm not quite keen on doing the File/Folder thing for some reason > (maybe I should be?). I don't see any other node types that disallow same > name siblings though. Does that mean I need to create my own node type? I would probably use an nt:folder for the container node and a new "atom:entry" subtype of nt:hierarchyNode for the entry nodes (or even nt:file with custom jcr:content resource nodes). The more you leverage the existing node types, the easier it will be to integrate with other JCR tools (for example a file system mapping will definitely know what to do with an nt:folder node). Alternatively, for maximum flexibility, you can create your node types from scratch. Either approach is valid. > And if I create my own node type does that mean I have to do so via the > Jackrabbit APIs? I don't see a way to do so via the JCR API. JCR 1.0 didn't standardize node type management (it'll be standardized in JCR 2.0), so currently you need to use a Jackrabbit-specific extension to register new types. See the JackrabbitNodeTypeManager extension interface in the jackrabbit-api package. BR, Jukka Zitting
