Thanks Shawn. Now I understand why my query without slop worked on the old system, not new one.
On top of this NGram phrase query, I also want to do some wildcards. I used complex phrase in my query. {!complexphrase inOrder=true}sequence:"KK?” worked debug":{ "rawquerystring":"{!complexphrase inOrder=true}sequence:\"KK?\"", "querystring":"{!complexphrase inOrder=true}sequence:\"KK?\"", "parsedquery":"ComplexPhraseQuery(\"KK?\")", "parsedquery_toString":"\"KK?\"", "explain":{ "ab95710d-f191-4c59-9df8-87e8bfe236ea":"\n0.48393333 = weight(sequence:kks in 0) [SchemaSimilarity], result of:\n 0.48393333 = score(doc=0,freq=1.0 = termFreq=1.0\n), product of:\n 0.2876821 = idf, computed as log(1 + (docCount - docFreq + 0.5) / (docFreq + 0.5)) from:\n 1.0 = docFreq\n 1.0 = docCount\n 1.682181 = tfNorm, computed as (freq * (k1 + 1)) / (freq + k1 * (1 - b + b * fieldLength / avgFieldLength)) from:\n 1.0 = termFreq=1.0\n 1.2 = parameter k1\n 0.75 = parameter b\n 115.0 = avgFieldLength\n 1.0 = fieldLength\n"}, "QParser":"ComplexPhraseQParser”, However, {!complexphrase inOrder=true}sequence:"KK? KSA”~1 does not work. "debug":{ "rawquerystring":"{!complexphrase inOrder=true}sequence:\"KK? KSA\"~1", "querystring":"{!complexphrase inOrder=true}sequence:\"KK? KSA\"~1", "parsedquery":"ComplexPhraseQuery(\"KK? KSA\"~1)", "parsedquery_toString":"\"KK? KSA\"~1", "explain":{}, "QParser":"ComplexPhraseQParser”, Chuming On Nov 16, 2017, at 11:49 AM, Shawn Heisey <apa...@elyograg.org> wrote: > On 11/16/2017 8:40 AM, Chuming Chen wrote: >> I think the position is the issue, but how do I fix it? Is something wrong >> with my index analyzer or just my query is not right? I need to do phrase >> query, order is important here. >> >> I tried “KKS KSA”~1 in the query, it worked. However, if I do "KKS KSA >> SAR”~1, it didn’t work, I had to do "KKS KSA SAR”~2. >> >> Is phrase slop essential here. I used to with Solr 3.5, no phrase slop is >> needed. > > The ~2 slop for the three-term query is correct -- because the third > term will have position 3 on the query, and position 1 in the index, so > it must adjust two places in order to match. > > If you look at the index analysis, you'll see that the positions of the > 3 character ngrams are all the same. I believe this is typical for that > filter, to maintain the position of the original term for all ngrams. > It wouldn't surprise me to learn that version 3.5 had very different > behavior in the ngram filter regarding positions, behavior that was > considered incorrect and fixed. > > I think this might be the applicable issue: > > https://issues.apache.org/jira/browse/LUCENE-4955 > > Thanks, > Shawn >