lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Todd Nine <>
Subject More information on Sort.INDEXORDER and porting TestNumericRange32
Date Thu, 07 Oct 2010 04:27:41 GMT
Hi all,
  I've been working on getting Uwe's numeric range query tests passing
on Lucandra, unfortunately it hasn't been as easy as I was hoping to get
working.  The term iterator now returns terms in the same order as the
RamDirectory in the original test case, so I'm getting valid documents.
However, for some reason the sort order of Sort.INDEXORDER is returning
a different order than the RamDirectory.  When specifying a specific
Sort, everything is sorted correctly.  So, I have a question regarding
the actual usage or Sort.INDEXORDER when used in the case below.

(from TestNumericRange32)

NumericRangeQuery q = NumericRangeQuery.newIntRange(field,
precisionStep, new Integer(lower), new Integer(upper), true, true);  
type = " (constant score filter rewrite)";
topDocs =, null, noDocs, Sort.INDEXORDER);
terms = q.getTotalNumberOfTerms();

Is Sort.INDEXORER = order of insertion, or equal to order of storage on
the underlying device?  Cassandra stores the documents and fields in the
following format

<index name>\<field name>\<field value(term)>

So for example, if the trie structure produces the following strings
(term value is represented as hex)

document 1

document 2

As you can see on the second shift trie, this will be stored on disk in
Cassandra with document 2 on before document 1 since the last 2 bytes
are smaller.  I'm also receiving the documents in this order, though
this is not what the test expects when it works with the RAMDirectory.


View raw message