Re: Problems with elevation component configuration
Created https://issues.apache.org/jira/browse/SOLR-10928 Support elevate.q in QueryElevationComponent to track this. -- View this message in context: http://lucene.472066.n3.nabble.com/Problems-with-elevation-component-configuration-tp3993204p4342075.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Problems with elevation component configuration
Hi, Well, if I understand correctly, only the search term is important for elevation, not the query. Anyway, we ended up modifying QueryElevationComponent class, extracting the search term from the query using regex. After that, it turned out that elevation doesn't work with grouped results, so we had to separate sorting for groups and non-groups in prepare() method of the same class. That was not the end of problems, because we need to show elevated results with a different styling, so we upgraded to Solr4 and now it seems to be working as expected. -- View this message in context: http://lucene.472066.n3.nabble.com/Problems-with-elevation-component-configuration-tp3993204p3995692.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Problems with elevation component configuration
: Thanks Chris, but actually, it turns out that "query text" from elevate.xml : has to match the query (q=...). So in this case, elevation works only for : http://localhost:8080/solr/elevate?q=brain, but not for : http://localhost:8080/solr/elevate?q=indexingabstract:brain type of queries. right ... query elevation by default is based on the raw query string. : but we have way more complicated queries which cannot be reduced just to : q=searchterm&... what would you want/exect QEC to do in that type of situation? how would it know what part of a complex query should/shouldn't be used for elevation? FWIW: ne thing you can do is configure a "queryFieldType" on in your QueryElevationComponent .. if specific, i will use the analyzer for that field type to process the raw query string before doing a lookup in the QEC data -- so for example: you could use it to lowercase the input, or strip out unwanted whitespace or punctuation. it night not help for really complicated queries, but it would let you easily deal with things like extra whitespace you want to ignore. I think it would also be fairly easy to make QEC support an "elevate.q" param similar to how there is a "spellcheck.q" param and a "hl.q" param to let the client specify an alternate, simplified, string for the feature to use -- feel free to open an issue for that and take a crack at a patch if you're interested. -Hoss
Re: Problems with elevation component configuration
Hi, Thanks Chris, but actually, it turns out that "query text" from elevate.xml has to match the query (q=...). So in this case, elevation works only for http://localhost:8080/solr/elevate?q=brain, but not for http://localhost:8080/solr/elevate?q=indexingabstract:brain type of queries. This could be solved by using DisMax query parser (http://localhost:8080/solr/elevate?q=brain&qf=indexingabstract&defType=dismax), but we have way more complicated queries which cannot be reduced just to q=searchterm&... Can anything be done about that without modifying QueryElevationComponent class? Thanks, Igor -- View this message in context: http://lucene.472066.n3.nabble.com/Problems-with-elevation-component-configuration-tp3993204p3994595.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Problems with elevation component configuration
Hi, Igor,
I also set forceElevation to true for my elevate results.
Cheers,
Chris
- Original Message -
From: Igor Salma
To: solr-user@lucene.apache.org
Cc:
Sent: Thursday, July 5, 2012 4:47 AM
Subject: Problems with elevation component configuration
Hi to all,
we are using solr in combination with nutch and there are multiple cores
defined under solr. From some reason we can't configure elevation request
handler. We followed the instruction on
http://wiki.apache.org/solr/QueryElevationComponent,
only changed node for queryFieldType to work with "text" type fields:
text
elevate.xml
explicit
elevator
and added the node in elevate.xml :
http://10.237.119.179:28080/ncal/mdo/presentation/conditions/conditionpage.jsp?condition=Condition_Epilepsy.xml";
/>
("id" field is the type of string and, as you can see, we are storing ulrs
as identifiers)
And when restart solr and try
http://localhost:8080/solr/elevate?q=indexingabstract:brain&debugQuery=true&enableElevation=truenothing
changes - the mentioned document is not on the top of the resut
list.
Can someone please help?
Thanks in advance,
Igor
Problems with elevation component configuration
Hi to all,
we are using solr in combination with nutch and there are multiple cores
defined under solr. From some reason we can't configure elevation request
handler. We followed the instruction on
http://wiki.apache.org/solr/QueryElevationComponent,
only changed node for queryFieldType to work with "text" type fields:
text
elevate.xml
explicit
elevator
and added the node in elevate.xml :
http://10.237.119.179:28080/ncal/mdo/presentation/conditions/conditionpage.jsp?condition=Condition_Epilepsy.xml";
/>
("id" field is the type of string and, as you can see, we are storing ulrs
as identifiers)
And when restart solr and try
http://localhost:8080/solr/elevate?q=indexingabstract:brain&debugQuery=true&enableElevation=truenothing
changes - the mentioned document is not on the top of the resut
list.
Can someone please help?
Thanks in advance,
Igor
