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)"; q.setRewriteMethod(MultiTermQuery.CONSTANT_SCORE_FILTER_REWRITE); topDocs = searcher.search(q, 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 time\createdtime\6669656c6438efbfbf600800012050 time\createdtime\6669656c6438efbfbf6804000050 time\createdtime\6669656c6438efbfbf70020000 time\createdtime\6669656c6438efbfbf780100 document 2 time\createdtime\6669656c6438efbfbf600800006c46 time\createdtime\6669656c6438efbfbf6804000036 time\createdtime\6669656c6438efbfbf70020000 time\createdtime\6669656c6438efbfbf780100 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. Thanks, Todd
