PS. this using jackrabbit 1.0.1. Upgrading now to see if fixed in later
version...
On 6/28/07, Mark Waschkowski <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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 < [EMAIL PROTECTED]> 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
