Interesting question - if you construct a multivalued field of non-tokenized
values, can you use a Lucene phrase query to match sequences of numeric
values? Seems like it should work!
Although, you couldn't write a quoted phrase of numeric values in most of
the query parsers since they depend on the analyzer to "tokenize" the quoted
string into individual terms, which the numeric field types would not do.
I'm too lazy to check to see what Lucene classes call the
getPositionIncrementGap method and what they do with its return value.
-- Jack Krupansky
-----Original Message-----
From: Alexandre Rafalovitch
Sent: Monday, October 13, 2014 10:37 AM
To: solr-user
Subject: Re: What happens if you don't set positionIncrementGap
On 13 October 2014 10:08, Shawn Heisey <apa...@elyograg.org> wrote:
I don't think it needs to be defined, but it can be thought of as
helpful to explicitly state a value in the example even if that value is
in fact the default, so a new user doesn't have to wonder what the value
is on those field types.
<rant>
I think the issue here is "helpful" vs. "information overload". I feel
each individual element is helpful but overall they become information
overload and people are just afraid to actually read through their
configuration files. Which means some other non-default
actually-important settings are missed as well. Which, ironically,
also negates "the user does not have to wonder" part because they
never get that far.
</rant>
After we verify that it is in fact unnecessary
How would we do that specifically? My intuition (probably wrong) says
that making that setting non-zero for dates/ints/longs does not
actually do anything useful at all. Or does it? How does the
phrase/proximity match works for non-text fields? I admit being
somewhat confused on that.
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resources and newsletter: http://www.solr-start.com/ and @solrstart
Solr popularizers community: https://www.linkedin.com/groups?gid=6713853
