jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jared Graber" <jared.gra...@IACcap.com>
Subject Query Bug?
Date Wed, 14 May 2008 15:35:46 GMT
I'm running an XPath query that is returning 2 score nodes.  

The problem is that only 1 of the nodes actually exist and the other
never existed (based on the UUID in the score node).

 

I am running in a very clean environment:

                Transient repository running in a previously empty
directory (no indices or anything)

                1 Thread (it's actually a unit test)

                

I checked the debug logs to see if the UUIDs mentioned in the score
nodes existed, and only 1 of the 2 were ever created (assuming the logs
are accurate).  I expected only 1 node to be returned based on the query
based on my query (I have 16 nodes in the repository at the time of the
unexpected result so I double checked the expected results).

 

I understand that the getSize() method of
org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl is not
guaranteed to be accurate because it loads the nodes lazily, but I think
it's a bug that the search returned 2 nodes in the first place.

 

It is of course possible to get around this issue by iterating over the
nodes (less than ideal of course) to get the correct count, but I'm
concerned that I am getting unexpected results to begin with.

 

Just out of curiosity, would the getSize() method be accurate if you're
running inside a transaction?

 

Also I find it unusual that the getSize() method does not strictly
follow the spec defined in the RangeIterator.  The documentation for
RangeIterator says that it should return the number of elements in the
iterator or -1 if the information is unavailable.  

I think DocOrderNodeIteratorImpl should return -1 if the real size is
unknown at the time of the request.

The user of the NodeIterator shouldn't need to know that the size can
change without directly modifying it.

 

-Jared


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