You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Mark Waschkowski <mw...@gmail.com> on 2007/06/26 20:21:27 UTC
difference between xpath searches
Hi,
I have noticed a difference between the below two methods for doing an xpath
search:
1) session.getRootNode().getNode(xPath);
2) Workspace ws = session.getWorkspace();
QueryManager qm = ws.getQueryManager();
Query q = qm.createQuery(xpath, Query.XPATH);
NodeIterator iter = q.execute().getNodes();
return iter;
In search #2, the session must be saved before the query will see newly
added nodes within the given session, but in search #1, the results WILL
include newly added nodes within the given session.
The database corollary would be seeing newly added rows within a particular
transaction, so it seems odd to me that search #2 wouldn't see newly added
nodes within the given session. Can anyone enlighten me as to why this is?
Thanks!
Mark
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Hi Jukka,
Hmm, that seems a bit funny to me, especially the part that says that if the
query result has nodes in it that are persisted, that they will reflect the
current state of the node *from the session*.
I'm going to restate this like so:
1) The NodeIterator from a query will never include nodes that have been
added within a session but not yet saved
2) A NodeIterator's node from a query will reflect the state of any changes
that have been made within the current session, whether or not they have yet
been persisted.
Again, seems funny to me that a NodeIterator from a query will not see
*additional nodes* from the current session, but will see *changes to nodes*
that are from the current session.
Am I missing something here, or is this just, um, the way things are?
Thanks,
Mark
On 6/26/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 6/26/07, Mark Waschkowski <mw...@gmail.com> wrote:
> > The database corollary would be seeing newly added rows within a
> particular
> > transaction, so it seems odd to me that search #2 wouldn't see newly
> added
> > nodes within the given session. Can anyone enlighten me as to why this
> is?
>
> The JCR spec actually mandates that the search results reflect the
> persisted state of the repository. See section 6.6.12 in the JCR spec
> for more details.
>
> BR,
>
> Jukka Zitting
>
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/26/07, Mark Waschkowski <mw...@gmail.com> wrote:
> The database corollary would be seeing newly added rows within a particular
> transaction, so it seems odd to me that search #2 wouldn't see newly added
> nodes within the given session. Can anyone enlighten me as to why this is?
The JCR spec actually mandates that the search results reflect the
persisted state of the repository. See section 6.6.12 in the JCR spec
for more details.
BR,
Jukka Zitting
Re: difference between xpath searches
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/27/07, Mark Waschkowski <mw...@gmail.com> wrote:
> JSR 170 repositories may provides completely different results
> depending on the context of the session, depending on which of the
> node retrieval methods are done, even if the *exact same* xpath is used.
Note that the argument to Node.getNode() is the relative JCR path of
the node to be retrieved, *not* an XPath query.
> Furthermore, why is the full text indexing mentioned as being potentially
> expensive when using Query but not when using session.getRootNode
> ().getNode(xpath)?
See above, getNode() is not a query.
BR,
Jukka Zitting
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Hi,
Thanks for the response Jukka.
I understand what you said, that JSR 170 considered it better to exclude
added nodes from the results. However, it really seems like a bad choice to
have the getNode(xpath) and the Query.execute() have different behaviors.
Hibernate, for example, supports criteria queries and HQL, but the
semantically similar query will always return the same results, as long as
executed within the same transaction. JSR 170 repositories may provides
completely different results depending on the context of the session,
depending on which of the node retrieval methods are done, even if the
*exact same* xpath is used.
Furthermore, why is the full text indexing mentioned as being potentially
expensive when using Query but not when using session.getRootNode
().getNode(xpath)?
I'm interested to hear your response, and if you don't think I'm out in left
field here, I may attempt to provide some feedback to JSR 283 about this.
Best,
Mark
On 6/27/07, Jukka Zitting <ju...@gmail.com> wrote:
>
> Hi,
>
> On 6/27/07, Mark Waschkowski <mw...@gmail.com> wrote:
> > 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.
>
> I agree that the behaviour seems strange if you come from a database
> background, where search (the ubiquitous SELECT) is the one and only
> way to access content. Typically content repository and JCR in
> particular offer a set of content traversal methods (like
> Node.getNode), which makes searching a more restricted use case. A
> typical access pattern would be to search for content to update, not
> to update content and then search for the changes.
>
> Also, as Felix mentioned many content repositories (including
> Jackrabbit) use full text indexing that makes index updates
> potentially expensive. So, since there typically isn't a need to
> search for unsaved changes, JSR 170 considered it better to exclude
> transient changes from the search index.
>
> BR,
>
> Jukka Zitting
>
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On 6/27/07, Mark Waschkowski <mw...@gmail.com> wrote:
> 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.
I agree that the behaviour seems strange if you come from a database
background, where search (the ubiquitous SELECT) is the one and only
way to access content. Typically content repository and JCR in
particular offer a set of content traversal methods (like
Node.getNode), which makes searching a more restricted use case. A
typical access pattern would be to search for content to update, not
to update content and then search for the changes.
Also, as Felix mentioned many content repositories (including
Jackrabbit) use full text indexing that makes index updates
potentially expensive. So, since there typically isn't a need to
search for unsaved changes, JSR 170 considered it better to exclude
transient changes from the search index.
BR,
Jukka Zitting
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Yes, you are right! Sorry about that, my repo must have gotten populated
during another test that was using the same node name :(
Best,
Mark
On 6/29/07, Marcel Reutegger <ma...@gmx.net> wrote:
>
> Mark Waschkowski wrote:
> > Ya, still a problem in 1.3.
> >
> > I've opened a jira (https://issues.apache.org/jira/browse/JCR-991), any
> > continuing assistance much appreciated.
>
> your test works fine, just make sure it operates on an empty repository.
>
> regards
> marcel
>
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Marcel Reutegger <ma...@gmx.net>.
Mark Waschkowski wrote:
> Ya, still a problem in 1.3.
>
> I've opened a jira (https://issues.apache.org/jira/browse/JCR-991), any
> continuing assistance much appreciated.
your test works fine, just make sure it operates on an empty repository.
regards
marcel
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Ya, still a problem in 1.3.
I've opened a jira (https://issues.apache.org/jira/browse/JCR-991), any
continuing assistance much appreciated.
Best,
Mark
On 6/28/07, Mark Waschkowski <mw...@gmail.com> wrote:
>
> PS. this using jackrabbit 1.0.1. Upgrading now to see if fixed in later
> version...
>
> On 6/28/07, Mark Waschkowski < mwaschkowski@gmail.com> wrote:
> >
> > Hi Jukka and Felix,
> >
> > Just wanted to let you know that beyond me learning some details about
> > jackrabbit, this conversation also spurred me to write a bit of test code to
> > increase my understanding, and I may have actually found a bug! The test
> > seems to show that a Query does actually see non-persistent results. I'm not
> > 100% sure about the test case, but looks reasonable enough to create a jira
> > about it to see what other people think. Feel free to contact me directly if
> > you would like.
> >
> > Best,
> >
> > Mark
> >
> > //would expect the last assertion to hold true unless the session is
> > saved
> > public void testSession() throws RepositoryException{
> > String parentNodeName = "documents";
> > Node parentNode = session.getRootNode().addNode(parentNodeName);
> >
> > String nodeName = "contact";
> > Node node = session.getRootNode
> > ().getNode(parentNodeName).addNode(nodeName);
> > node.setProperty ("firstName", "joe");
> >
> > Node contactNode = session.getRootNode().getNode(parentNodeName +
> > "/" + nodeName);
> > assertNotNull(contactNode);
> >
> > String xpath = parentNodeName;
> > NodeIterator ni = session.getRootNode().getNode(xpath).getNodes();
> > System.out.println("ni count =" + ni.getSize());
> > String name1 = ni.nextNode().getName().toString();
> > System.out.println ("Found node using getNode(xpath):" + name1);
> >
> > //session.save();
> > Workspace ws = session.getWorkspace();
> > QueryManager qm = ws.getQueryManager();
> > Query q = qm.createQuery (xpath, Query.XPATH);
> > NodeIterator iter = q.execute().getNodes();
> > while(iter.hasNext()){
> > Node queryNode = iter.nextNode();
> > System.out.println("Found node using Query:" + queryNode.getName());
> > }
> >
> > System.out.println("iter size=" + iter.getSize());
> > assertEquals(0, iter.getSize());
> > }
> >
> >
> > On 6/28/07, Mark Waschkowski <mw...@gmail.com> wrote:
> > >
> > > Hi Felix,
> > >
> > > Ya, I hear what you are saying, and respect it. As a user and a
> > > developer who sees significant similarities between the two node retrieval
> > > methods I just believe they should have similar semantics (and just because
> > > the spec says that its this way doesn't make it right ;)
> > >
> > > Thank you very much for your insights, you've been very helpful.
> > >
> > > Best,
> > >
> > > Mark
> > >
> > > On 6/28/07, Felix Meschberger < Felix.Meschberger@day.com> wrote:
> > > >
> > > > Hi Mark,
> > > >
> > > > I just reiterate, what has been said before: The argument to the
> > > > Node.getNode(String path) method is NOT an xpath query, so the
> > > > results are
> > > > not expected to be the same. Also, the specification is different
> > > > for the
> > > > getNode method and Query.execute methods.
> > > >
> > > > All in all, there is no inconsistency between the two
> > > > functionalities,
> > > > because they are completely different. The two are two ways of
> > > > achieving
> > > > different goals, they are by no means two ways to achieve the same
> > > > goal.
> > > >
> > > > Regards
> > > > Felix
> > > >
> > > > On 6/27/07, Mark Waschkowski < mwaschkowski@gmail.com> wrote:
> > > > >
> > > > > 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,
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best,
> > >
> > > Mark Waschkowski
> >
> >
> >
> >
> > --
> > Best,
> >
> > Mark Waschkowski
>
>
>
>
> --
> Best,
>
> Mark Waschkowski
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
PS. this using jackrabbit 1.0.1. Upgrading now to see if fixed in later
version...
On 6/28/07, Mark Waschkowski <mw...@gmail.com> wrote:
>
> Hi Jukka and Felix,
>
> Just wanted to let you know that beyond me learning some details about
> jackrabbit, this conversation also spurred me to write a bit of test code to
> increase my understanding, and I may have actually found a bug! The test
> seems to show that a Query does actually see non-persistent results. I'm not
> 100% sure about the test case, but looks reasonable enough to create a jira
> about it to see what other people think. Feel free to contact me directly if
> you would like.
>
> Best,
>
> Mark
>
> //would expect the last assertion to hold true unless the session is saved
> public void testSession() throws RepositoryException{
> String parentNodeName = "documents";
> Node parentNode = session.getRootNode().addNode(parentNodeName);
>
> String nodeName = "contact";
> Node node = session.getRootNode
> ().getNode(parentNodeName).addNode(nodeName);
> node.setProperty ("firstName", "joe");
>
> Node contactNode = session.getRootNode().getNode(parentNodeName + "/"
> + nodeName);
> assertNotNull(contactNode);
>
> String xpath = parentNodeName;
> NodeIterator ni = session.getRootNode().getNode(xpath).getNodes();
> System.out.println("ni count =" + ni.getSize());
> String name1 = ni.nextNode().getName().toString();
> System.out.println ("Found node using getNode(xpath):" + name1);
>
> //session.save();
> Workspace ws = session.getWorkspace();
> QueryManager qm = ws.getQueryManager();
> Query q = qm.createQuery (xpath, Query.XPATH);
> NodeIterator iter = q.execute().getNodes();
> while(iter.hasNext()){
> Node queryNode = iter.nextNode();
> System.out.println("Found node using Query:" + queryNode.getName());
> }
>
> System.out.println("iter size=" + iter.getSize());
> assertEquals(0, iter.getSize());
> }
>
>
> On 6/28/07, Mark Waschkowski <mw...@gmail.com> wrote:
> >
> > Hi Felix,
> >
> > Ya, I hear what you are saying, and respect it. As a user and a
> > developer who sees significant similarities between the two node retrieval
> > methods I just believe they should have similar semantics (and just because
> > the spec says that its this way doesn't make it right ;)
> >
> > Thank you very much for your insights, you've been very helpful.
> >
> > Best,
> >
> > Mark
> >
> > On 6/28/07, Felix Meschberger < Felix.Meschberger@day.com> wrote:
> > >
> > > Hi Mark,
> > >
> > > I just reiterate, what has been said before: The argument to the
> > > Node.getNode(String path) method is NOT an xpath query, so the results
> > > are
> > > not expected to be the same. Also, the specification is different for
> > > the
> > > getNode method and Query.execute methods.
> > >
> > > All in all, there is no inconsistency between the two functionalities,
> > >
> > > because they are completely different. The two are two ways of
> > > achieving
> > > different goals, they are by no means two ways to achieve the same
> > > goal.
> > >
> > > Regards
> > > Felix
> > >
> > > On 6/27/07, Mark Waschkowski < mwaschkowski@gmail.com> wrote:
> > > >
> > > > 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,
> > > >
> > >
> >
> >
> >
> > --
> > Best,
> >
> > Mark Waschkowski
>
>
>
>
> --
> Best,
>
> Mark Waschkowski
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Hi Jukka and Felix,
Just wanted to let you know that beyond me learning some details about
jackrabbit, this conversation also spurred me to write a bit of test code to
increase my understanding, and I may have actually found a bug! The test
seems to show that a Query does actually see non-persistent results. I'm not
100% sure about the test case, but looks reasonable enough to create a jira
about it to see what other people think. Feel free to contact me directly if
you would like.
Best,
Mark
//would expect the last assertion to hold true unless the session is saved
public void testSession() throws RepositoryException{
String parentNodeName = "documents";
Node parentNode = session.getRootNode().addNode(parentNodeName);
String nodeName = "contact";
Node node = session.getRootNode
().getNode(parentNodeName).addNode(nodeName);
node.setProperty("firstName", "joe");
Node contactNode = session.getRootNode().getNode(parentNodeName + "/" +
nodeName);
assertNotNull(contactNode);
String xpath = parentNodeName;
NodeIterator ni = session.getRootNode().getNode(xpath).getNodes();
System.out.println("ni count =" + ni.getSize());
String name1 = ni.nextNode().getName().toString();
System.out.println("Found node using getNode(xpath):" + name1);
//session.save();
Workspace ws = session.getWorkspace();
QueryManager qm = ws.getQueryManager();
Query q = qm.createQuery(xpath, Query.XPATH);
NodeIterator iter = q.execute().getNodes();
while(iter.hasNext()){
Node queryNode = iter.nextNode();
System.out.println("Found node using Query:" + queryNode.getName());
}
System.out.println("iter size=" + iter.getSize());
assertEquals(0, iter.getSize());
}
On 6/28/07, Mark Waschkowski <mw...@gmail.com> wrote:
>
> Hi Felix,
>
> Ya, I hear what you are saying, and respect it. As a user and a developer
> who sees significant similarities between the two node retrieval methods I
> just believe they should have similar semantics (and just because the spec
> says that its this way doesn't make it right ;)
>
> Thank you very much for your insights, you've been very helpful.
>
> Best,
>
> Mark
>
> On 6/28/07, Felix Meschberger < Felix.Meschberger@day.com> wrote:
> >
> > Hi Mark,
> >
> > I just reiterate, what has been said before: The argument to the
> > Node.getNode(String path) method is NOT an xpath query, so the results
> > are
> > not expected to be the same. Also, the specification is different for
> > the
> > getNode method and Query.execute methods.
> >
> > All in all, there is no inconsistency between the two functionalities,
> > because they are completely different. The two are two ways of achieving
> > different goals, they are by no means two ways to achieve the same goal.
> >
> > Regards
> > Felix
> >
> > On 6/27/07, Mark Waschkowski < mwaschkowski@gmail.com> wrote:
> > >
> > > 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,
> > >
> >
>
>
>
> --
> Best,
>
> Mark Waschkowski
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
Hi Felix,
Ya, I hear what you are saying, and respect it. As a user and a developer
who sees significant similarities between the two node retrieval methods I
just believe they should have similar semantics (and just because the spec
says that its this way doesn't make it right ;)
Thank you very much for your insights, you've been very helpful.
Best,
Mark
On 6/28/07, Felix Meschberger <Fe...@day.com> wrote:
>
> Hi Mark,
>
> I just reiterate, what has been said before: The argument to the
> Node.getNode(String path) method is NOT an xpath query, so the results are
> not expected to be the same. Also, the specification is different for the
> getNode method and Query.execute methods.
>
> All in all, there is no inconsistency between the two functionalities,
> because they are completely different. The two are two ways of achieving
> different goals, they are by no means two ways to achieve the same goal.
>
> Regards
> Felix
>
> On 6/27/07, Mark Waschkowski <mw...@gmail.com> wrote:
> >
> > 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,
> >
>
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Felix Meschberger <Fe...@day.com>.
Hi Mark,
I just reiterate, what has been said before: The argument to the
Node.getNode(String path) method is NOT an xpath query, so the results are
not expected to be the same. Also, the specification is different for the
getNode method and Query.execute methods.
All in all, there is no inconsistency between the two functionalities,
because they are completely different. The two are two ways of achieving
different goals, they are by no means two ways to achieve the same goal.
Regards
Felix
On 6/27/07, Mark Waschkowski <mw...@gmail.com> wrote:
>
> 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,
>
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
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 <Fe...@day.com> wrote:
>
> Hi Mark,
>
> On 6/27/07, Mark Waschkowski <mw...@gmail.com> 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
Re: difference between xpath searches
Posted by Felix Meschberger <Fe...@day.com>.
Hi Mark,
On 6/27/07, Mark Waschkowski <mw...@gmail.com> 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
Re: difference between xpath searches
Posted by Mark Waschkowski <mw...@gmail.com>.
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 <Fe...@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
>
--
Best,
Mark Waschkowski
Re: difference between xpath searches
Posted by Felix Meschberger <Fe...@day.com>.
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