: Ok, it has been resolved. I was lucky to have spotted i was looking at 
: the wrong schema fike! The one the test actually used was not yet 
: updated from Trie to Point!

And boom goes the dynamite.

This is a prime example of where having assumptions in your code (that the 
field type will by an IntPoint field) can bite you in the ass if/hen the 
schema changes (or when it was never changed and still used old TrieInt) 
but if you use proper delgation to get hte SchemaField from the schema, 
and then ask the SchemaField's FieldType to build you a range query) 
everything will work even if/when the schema is edited.


: 
: Thanks!
: Markus
: 
:  
:  
: -----Original message-----
: > From:Markus Jelsma <markus.jel...@openindex.io>
: > Sent: Tuesday 3rd October 2017 15:18
: > To: solr-user@lucene.apache.org; Solr-user <solr-user@lucene.apache.org>
: > Subject: RE: Moving to Point, trouble with IntPoint.newRangeQuery()
: > 
: > 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"));
: >     assertU(commit());
: >     assertQ(
: >         req("q", "{!qdigest field=digest1}", "debug", "true", "indent", 
"true"), 
: >             "//result/doc[1]/str[@name='id'][.='8']");
: >   }
: > 
: > The following parse() implementation passes (because it simply uses 
LuceneQParser syntax):
: > 
: >   @Override
: >   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:
: > 
: >   @Override
: >   public Query parse() throws SyntaxError {
: >     BooleanQuery.Builder builder = new BooleanQuery.Builder();
: >     Query pointQuery = IntPoint.newRangeQuery("digest1", -1820898630, 
-1820898630);
: >     builder.add(pointQuery, Occur.SHOULD);
: >     return builder.build();
: >   }
: > 
: > 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,
: > Markus
: > 
: >  
: >  
: > -----Original message-----
: > > From:Chris Hostetter <hossman_luc...@fucit.org>
: > > Sent: Tuesday 26th September 2017 18:52
: > > To: Solr-user <solr-user@lucene.apache.org>
: > > 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
: > > http://www.lucidworks.com/
: > > 
: > 
: 

-Hoss
http://www.lucidworks.com/

Reply via email to