Hi, Thanks Jukka and Felix for the clarifications. I understand now that the call to getNode cannot be a query. Please allow me to restate:
Node retrieval is not handled consistently when retrieving nodes using an xpath that refers to a particular location within the repository. For example do the following: 0) define xpath == '/documents/contacts' 1) create a session 2) add a node in documents/contacts 3) retrieve your nodes by using 3a or 3b 3a) session.getRootNode().getNode(xpath).getNodes() 3b) Workspace ws = session.getWorkspace(); QueryManager qm = ws.getQueryManager(); Query q = qm.createQuery(xpath, Query.XPATH); NodeIterator iter = q.execute().getNodes(); You will, as mandated by the spec, get different results! I believe that the nodes returned should be consistent regardless of Node retrieval access, either both with the added node, or both without. Best, Mark On 6/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hi Mark, On 6/27/07, Mark Waschkowski <[EMAIL PROTECTED]> wrote: > > Hi Felix, > > Thanks for the response. Please allow me to clarify the first point, I'm > actually referring to exactly what is stated, the getNode(xPath) method. I > see an xpath statement as a type of search because any given xpath may be > a > simple path, but often includes some kind of criteria for the result set. Thanks for the clarification. Now, there is another misconception, unfortunately. The path argument to the Node.getNode(String) method is not an XPath querry but a relative path with no pattern characters allowed. This is for direct addressing of a single child (or descendent) node. This method just walks down the node hierarchy without applyiing any pattern matching. Regards Felix
-- Best, Mark Waschkowski
