jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Waschkowski" <mwaschkow...@gmail.com>
Subject Re: difference between xpath searches
Date Wed, 27 Jun 2007 12:40:07 GMT
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?



On 6/27/07, Felix Meschberger <Felix.Meschberger@day.com> 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


Mark Waschkowski

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message