lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Jelsma <>
Subject RE: Moving to Point, trouble with IntPoint.newRangeQuery()
Date Tue, 03 Oct 2017 13:17:48 GMT
Ok, i have stripped down the QParser to demonstrate the problem. This is the basic test with
only one document in the index:

  public void testPointRange() throws Exception {
    assertU(adoc("id", "8", "digest1", "-1820898630"));
        req("q", "{!qdigest field=digest1}", "debug", "true", "indent", "true"), 

The following parse() implementation passes (because it simply uses LuceneQParser syntax):

  public Query parse() throws SyntaxError {
    QParser luceneQParser = new LuceneQParser("digest1:[-1820898630 TO -1820898630]", localParams,
params, req);
    return luceneQParser.parse();

But when i switch to a BooleanQuery with just one RangeQuery, it fails:

  public Query parse() throws SyntaxError {
    BooleanQuery.Builder builder = new BooleanQuery.Builder();
    Query pointQuery = IntPoint.newRangeQuery("digest1", -1820898630, -1820898630);
    builder.add(pointQuery, Occur.SHOULD);

I might be overlooking things but i really don't so the problem with the second parse() impl.

What am i doing wrong?

Many thanks,

-----Original message-----
> From:Chris Hostetter <>
> Sent: Tuesday 26th September 2017 18:52
> To: Solr-user <>
> Subject: Re: Moving to Point, trouble with IntPoint.newRangeQuery()
> : I have a QParser impl. that transforms text input to one or more 
> : integers, it makes a BooleanQuery one a field with all integers in 
> : OR-more. It used to work by transforming the integer using 
> : LegacyNumericUtils.intToPrefixCoded, getting a BytesRef.
> : 
> : I have now moved it to use IntPoint.newRangeQuery(field, integer, 
> : integer), i read (think javadocs) this is the way to go, but i get no 
> : matches!
> As a general point: if you want to do this in a modular way, you should 
> fetch the FieldType from the IndexSchema and use the 
> FieldType.getRangeQuery(...) method.
> That said -- at a quick glance, knowing how your schema is defined, i'm 
> not sure why/how your IntPoint.newRangeQuery() code would fail.
> Maybe add a lower level test of the QParser directly and assert some 
> explicit properties on the Query objects? (class, etc...)
> -Hoss

View raw message