The normal solution would be - as you already noted - to start the
xpath query with baseNode.getPath(). You are right that resolving the
parent path is not needed in the overall use case "search below a
given node", but it shouldn't be a performance killer, since the path
to the root normally consists of only a handful nodes. Or do you see a
performance issue in your environment?
Regards,
Alex
Am 26.03.2008 um 06:49 schrieb Dave Brosius:
I am interested in doing descendant based patch constrained queries.
I read section "6.6.3.4 Path Constraint", and infer that in order to
specify path constraints, you must know the full path to the node at
which you are constraining. These seems odd to me. Why doesn't jcr
follow the pattern set by xpath, that being the availability of
relative and absolute xpaths (queries).
Why doesn't the query object have a
query.setContextNode(node), which specifies from which node the
query begins?
How does one determing the absolute path of a node that you have
retreived by uuid? Do we really need to do a recursive getParent
search to the root? Or, do i really need to store the absolute path
of each node in a node property? This seems really painful. I see
the property jcr:path, but this is apparently only a pseudo property
available only from within the query itself.
So the question is how do people do a descendent path constraining
query when you want to start the search at any arbitrary node that
is retrieved by UUID?
--
Alexander Klimetschek
[EMAIL PROTECTED]
