No, omitTermFreqAndPositions and omitNorms parameter must be set in the definition of the field in the schema.xml. (in the example config is shown).
Have you analyzed the scoring information produced by debugQuery=true? Add that to the query parameters. That will produce information for each document. Compare how the score is calculated in the case of the (undesired) first document, and in the case of the relevant document that should be the first. That should show you why the score is not being calculated correctly. Also, it may not apply to your case but qs should be higher than 0 mm can be interfering. Remove it for testing if the problem persists. Thanks http://wiki.apache.org/solr/CommonQueryParameters#debugQuery 2012/1/9 McCarroll, Robert <robert.mccarr...@cs.state.ny.us>: > The query comes off of the search page looking like: > > <tomcatservername>:<port>/solr_<instance>/select?q=Budget%20Examiner%2FBudget%20Examiner%20%28Public%20Finance%29&hl=true&hl.fragsize=200&wt=json&start=0 > > And the solrconfig section for the parser in use looks like: > > <requestHandler name="dismax" class="solr.SearchHandler" default="true"> > <lst name="defaults"> > <str name="defType">dismax</str> > <str name="echoParams">explicit</str> > <float name="tie">0.01</float> > <str name="pf"> > title^5000.0 content id^2000.0 > </str> > <str name="mm"> > 2<-1 5<-2 6<90% > </str> > <int name="ps">3</int> > <str name="qf">title^5000.0 id^2000.0 content</str> > <int name="qs">0</int> > <!-- <str name="fl">title,id,url,boost,score</str> --> > <str name="hl.fl">content</str> > <str name="f.name.hl.fragsize">0</str> > <str name="f.name.hl.alternateField">title</str> > <str name="f.text.hl.fragmenter">regex</str> <!-- defined below --> > </lst> > </requestHandler> > > The high boost numbers were set as part of an attempt to see if we could get > the title match to come up to the first page of results. It started out at > about 5 and 2 for id. (id in this case being the URL of the page). > > If I wanted to ass the omitTermFreqAndPositions to qf, would it look like > something like: > > <str name="qf" omitTermFreqAndPositions=false>title^5000.0 id^2000.0 > content</str> > > ? > > > Robert McCarroll > Systems Administration > NYS Department of Civil Service > > > > > -----Original Message----- > From: Emmanuel Espina [mailto:espinaemman...@gmail.com] > Sent: Monday, January 09, 2012 1:42 PM > To: solr-user@lucene.apache.org > Subject: Re: Match raw query string > > How are you building your query? For your case it appears that the > edismax query parser should solve it > > A good solution to this kind of problem involves: > Storing norms (omitNorms=false) in the fields to search > Storing the position of the terms (omitTermFreqAndPositions=false) in > the fields to search > Configuring dismax so the title gets a higher boost (qf parameter > configured to something like "title^3 body") > Configuring dismax so phrase queries in the title gets an even higher > boost (pf parameter configured to something like "title^10 body") > > References: > http://wiki.apache.org/solr/DisMaxQParserPlugin > http://wiki.apache.org/solr/SchemaXml > > > 2012/1/9 McCarroll, Robert <robert.mccarr...@cs.state.ny.us>: >> We're in the process of implementing solr to search our web site, and >> have run into a response tuning issue. When a user searches for a >> string which is an exact match of a document title, for example "Budget >> Examiner/Budget Examiner(Public Finance)", the number of hits in the >> body of much longer pages on words stemming from the same roots drowns >> out the exact title match so that it is deeply buried in the search >> results, regardless of how much weight is given to the title field. Is >> there a way to configure solr so that raw query string matches for query >> strings of more than two or three words appear before all other search >> results, followed by non-exact title matches and have content matches >> sort last? >> >> >> Robert McCarroll >> Systems Administration >> NYS Department of Civil Service >> >> >>
