Many thanks for the advice, Alex. I will definitely consider implementing your ideas, whether that is in this current project or a future one... it sounds like it may be more disruptive and time consuming than it is worth to now make these changes :S
I have not really found a need to have a name-readable path. Most of my custom nodes extend nt:unstructured and mix:referenceable and I have got in the habit of looking up nodes by a given UUID. My original thinking was that if the repository structure was to change, a query can search by custom node type (using property constraints if needs be) rather than assuming and trying to stick to a rigid structure. In fact, the structure has changed a number of times throughout the project to date so path-based navigation and retrieval would have broken numerous times. Regarding SQL2 joins, I was disappointed with the performance of the ISDESCENDENTNODE join on clause so ended up getting rid of it and putting a parent reference in to the child node. Probably most likely that I wasn't using it properly. I couldn't find much in the way of documentation on the function, though. Many thanks once again for you help. Regards, James -- View this message in context: http://n4.nabble.com/Query-vs-Manual-Node-Iteration-tp1599098p1599280.html Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
