My actual problem is with elevate not working with "exclusive=true". I have a special pinned widget, that has to display only the nodes defined in my elevate.xml, kind of sponsored results.
If I define "game" in my elevte.xml, and send "exclusive=true" I get only the elevated entries. http://<my domain>:8181/solr/elevate?q=game&wt=xml&sort=score+desc&fl=id,bundle_name&exclusive=true but when I pass a word not defined in my elevate.xml, and send "exclusive=true", I almost get same results like /select query. http://<my domain>:8181/solr/elevate?q=gamenotdefined&wt=xml&sort=score+desc&fl=id,bundle_name&exclusive=true So I ended up in using both elevate and select, if numbers [numFound] MATCH in both the request, I assume the word does not exist in my elevate.xml, and I had to hide my pinned widget. But in few cases, my /elevate and /select are not returning same numFound. There are some differences in the numbers. Is there a way to force "exclusive=true" just to look at elevate.xml entries, and ignore the result from default search? answer to your questions: 1. There is no exclude=true parameter set in my elevate.xml 2. There is no exlusive=true set in url 3. My elevate entry in solrconfig.xml <searchComponent name="elevator" class="solr.QueryElevationComponent"> <!-- pick a fieldType to analyze queries --> <str name="queryFieldType">string</str> <str name="config-file">elevate.xml</str> <!-- <str name="refreshOnCommmit">true</str> --> </searchComponent> <!-- a request handler utilizing the elevator component --> <requestHandler name="/elevate" class="solr.SearchHandler" startup="lazy"> <lst name="defaults"> <str name="echoParams">explicit</str> </lst> <arr name="last-components"> <str>elevator</str> </arr> </requestHandler> 4. I am not sure how to verify qf difference. I am using raw schema.xml and solrconfig.xml shipped with drupal solr module. I manage most of the solr configs via the drupal module, except at query time I query solr queries directly. -----Original Message----- From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Friday, May 04, 2012 5:44 PM To: solr-user@lucene.apache.org Subject: Re: elevate vs. select numFound results Some ways that fewer docs might be returned by query elevation: 1. The "excude" option: exclude="true" in the xml file. 2. The "exclusive" request parameter: &exclusive=true in the URL. (Certainly not your case.) 3. The "exclusive" request parameter default set to "true" in "defaults" for the "/elevate" request handler in solrconfig. 4. Some other query-related parameters (e.g., "qf") are different between your "/select" and "/elevate" request handlers Try adding &enableElevation=false to your URL for "/elevate", which should show you whether query elevation itself is affecting the number of docs, or if it must be some other parameters that are different between the two request handlers. -- Jack Krupansky -----Original Message----- From: roxy.noord...@wwecorp.com Sent: Friday, May 04, 2012 3:21 PM To: solr-user@lucene.apache.org Subject: elevate vs. select numFound results I need help understanding the difference in the numFound number in the result when I execute two queries against my solr instance, one with the elevation and one without. I have a simple elevate.xml file created and working and am searching for terms that are not meant to be elevated. Elevate query example.com:8080/solr/elevate?q=dwayne+rock+johnson&wt=xml&sort=score+desc&rows=1 for this the numFound is 125 in the result element of the XML Select query example.com:8080/solr/select?q=dwayne+rock+johnson&wt=xml&sort=score+desc&rows=1 for this the numFound is 154 in the result element of the XML For many (most all) of my queries the numFound results are the same (both with elevated query strings and with strings not in elevate.xml), but this one is very different. Should they be the same? Any idea what could make them different? Thank you. -- View this message in context: http://lucene.472066.n3.nabble.com/elevate-vs-select-numFound-results-tp3963200.html Sent from the Solr - User mailing list archive at Nabble.com.
