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. And, of course, any wildcard characters in an xpath means that a search occurs with jackrabbit, which is also very common.
Regarding your last paragraph, 'potentially expensive operation' is the key part I believe. I still, unfortunately, am unsure of some of the details here and how they relate to the spec. First off, let me state that I think a query not seeing nodes that have been added within the current session is counter-intuitive because of how transaction contexts typically work within a database: if you insert a row into a table, but its not committed yet, you can still 'see' the new row from with your transactional context. Now, updates are seen from a session, but not additions. So that means as query results (due to a query execution) are iterated through, some checking occurs to see if the node returned by the iterator is the same as that of a node that has been changed within the current session. If the node has been changed, then the query results will reflect the change. OK, so far so good. Since checks are occurring for updated nodes, why not checks to occur for added nodes? Added nodes could be appended to iterator, although ordering would be lost. Is this the underlying reason for the spec stating that query results are returned from the persisted state, ordering? Best, Mark On 6/27/07, Felix Meschberger <[EMAIL PROTECTED]> wrote:
Hi Mark, There is some misconception here :-) 1) session.getRootNode().getNode(xPath); This is not a search/query: - assuming you mean Node.getNodes(String) [ watch the trailing s ] - the "xPath", actually pattern, argument you submit may not be an XPath query but a simplified pattern, which only allows listing the direct child nodes. This method is specified to return whatever is in the node currently as seen from the session. If there are modifications (new nodes, removed nodes), these are reflected in the NodeIterator returned. 2) Workspace ws = session.getWorkspace(); > QueryManager qm = ws.getQueryManager(); > Query q = qm.createQuery(xpath, Query.XPATH); > NodeIterator iter = q.execute().getNodes(); > return iter; As Jukka already said, a query operates on the persistent state of nodes. That is only persisted nodes and properties will be looked up and considered for XPath query execution. The result however might include modifications. Consider a node /a/b which is modifed but not stored. If the search would return that node, you would get the modified node /a/b from the node iterator and not the persisted one. The reason for only operating on persisted items is, that updating a search index is a potentially expensive operation, which you would want to postpone to the moment, when you are prepared to do expensive operations - e.g. upon a save operation. Hope this helps Regards Felix
-- Best, Mark Waschkowski
