On 8/1/2013 4:35 AM, vehovmar wrote: > I have serious problems when upgrading to new solr 4.3/4.4 Search results do > not make sense. I reindexed everithing and I'm still getting wierd result. I > have pretty complicated config, using edismax requestHandler with boosting > > <str name="qf">name^2.0 man^1.0</str> > <str name="pf">name^2.0 man^1.0</str> > <str name="bf">users^2 shops^1.5</str>
Side issue: The "bf" parameter is for a boost function. It doesn't mean boost fields. What you have here for bf may not be not correct. http://wiki.apache.org/solr/ExtendedDisMax#bf_.28Boost_Function.2C_additive.29 > Schema: (same for "query") > analyzer type="index"> > <tokenizer class="solr.WhitespaceTokenizerFactory"/> > <filter class="solr.StopFilterFactory" ignoreCase="true" > words="hce_stopwords.txt" enablePositionIncrements="true" /> > <filter class="solr.SynonymFilterFactory" > synonyms="hce_synonyms.txt" ignoreCase="true" expand="false"/> > <filter class="solr.WordDelimiterFilterFactory" > generateWordParts="1" generateNumberParts="1" catenateWords="1" > catenateNumbers="0" catenateAll="0" splitOnCaseChange="1" > splitOnNumerics="1" /> > <filter class="solr.ICUFoldingFilterFactory"/> > <filter class="solr.EdgeNGramFilterFactory" minGramSize="1" > maxGramSize="15" side="front" /> > </analyzer> Most likely the reason it's matching is because of the EdgeNGramFilter. This results of analysis on both your query (nokia) and your indexed value (Nikon D5100) will have "n" as a term. You may want to consider using the EdgeNGramFilter on only one side - either index or query. I believe that in situations where it is only applied to one side, it's done on the index side. I'm not 100% sure about that, though. Thanks, Shawn
