Naming nodes in content repository

Question

What should the nodes in a content repository like JackRabbit be named? I don't understand whether I name them after an id, text etc.

Let say you were about to store blog pages. Should you use the title or what?

Answer 1

It doesn't really matter what they are named. If possible, name them something that means something to your application: customer name, order ID, username, attachment filename, etc. But that's difficult to do in all situations (e.g., questions on a Q&A site), so you may need to resort to naming nodes by some generated key or identifier.

No matter what you name the nodes, be sure that your node structure is a hierarchy and not a flat structure (e.g., with tens of thousands of child nodes under a single parent). JCR repositories are inherently hierarchical, and will always perform better when the structure is hierarchical.

For example, "/orders/{id}" will work with small numbers of customers, but will struggle when the number of customers is more than several thousand. If possible, use additional layers that will subdivide the {id} value space into manageable portions. Dates sometimes work:

/orders/yyyy/mm/dd/{id}

or if the id values are sufficiently random and well-distributed (e.g., UUIDs or SHA1s), then you can subdivide using portions of the id:

/orders/{id-chars1-2}/{id-chars3-4}/{id}

Also, with JCR same-name-siblings work well when ensuring non-duplicates is difficult. Generally, same-name-siblings are problematic because the paths can change, making it difficult for applications that rely upon paths (even for a short period of time, e.g., between requests). However, if the application always reads the SNS children and processes them immediately, then same-name-siblings might be acceptable for your application.

Often, paths are used in place of REFERENCE or WEAKREFERENCE properties, and in these cases SNS nodes are really bad since the "reference paths" aren't durable. If you use SNS nodes, then consider using some kind of reference property. REFERENCE and WEAKREFERENCE are bi-directional, but implementations may offer alternatives. For example, ModeShape offers "SIMPLE_REFERENCE" properties that are non-standard but uni-directional, meaning you can have any number of SIMPLE_REFERENCE property values pointing to a single referenceable node with no scalability problems.