You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Ryan Grange <rg...@dollardays.com> on 2010/03/09 06:34:51 UTC

QueryElevationComponent blues

Using Solr 1.4.
Was using the standard query handler, but needed the boost by field 
functionality of qf from dismax.
So we altered the query to boost certain phrases against a given field.
We were using QueryElevationComponent ("elevator" from solrconfig.xml) 
for one particular entry we wanted at the top, but because we aren't 
using a pure q value, elevator never finds a match to boost.  We didn't 
realize it at the time because the record we were elevating eventually 
became the top response anyway.
Recently added a _val_:formula to the q value to juice records based on 
a value in the record.
Now we have need to push a few other records to the top, but we've lost 
the ability to use elevate.xml to do it.

Tried switching to dismax using qf, pf, qs, ps, and bf with a "pure" q 
value, and debug showed queryBoost with a match and records, but they 
weren't moved to the top of the result set.

What would really help is if there was something for elevator akin to 
spellcheck.q like elevation.q so I could pass in the actual user phrase 
while still performing all the other field score boosts in the q 
parameter. Alternatively, if anyone can explain why I'm running into 
problems getting QueryElevationComponent to move the results in a dismax 
query, I'd be very thankful.

-- 
Ryan T. Grange


Re: QueryElevationComponent blues

Posted by Ryan Grange <rg...@dollardays.com>.
I'd read that too, but in the debug data queryBoosting is showing 
matches on our int typed identifiers (though it does show it as 
<str>123456</str>).  Is the problem that it can match against an 
integer, but it can't reorder them in the results?  This seems unlikely 
as using a standard query and elevation does cause otherwise lower 
results to jump to the top of the results.

I've looked at the source and noticed the check for a string type in 
there.  I'm not sure why my Solr instance seems okay with an int for a 
unique identifier.

Tried forceElevation=true with qt=dismax and still no effect on placement.

We don't want to give up field, phrase, and formula boosting when using 
the standard request handler just to have elevation work.

Ryan T. Grange, IT Manager
DollarDays International, Inc.
rgrange@dollardays.com (480)922-8155 x106


On 3/8/2010 11:13 PM, Jon Baer wrote:
> Maybe some things to try:
>
> * make sure your uniqueKey is string field type (ie if using int it will not work)
> * forceElevation to true (if sorting)
>
> - Jon
>
> On Mar 9, 2010, at 12:34 AM, Ryan Grange wrote:
>
>    
>> Using Solr 1.4.
>> Was using the standard query handler, but needed the boost by field functionality of qf from dismax.
>> So we altered the query to boost certain phrases against a given field.
>> We were using QueryElevationComponent ("elevator" from solrconfig.xml) for one particular entry we wanted at the top, but because we aren't using a pure q value, elevator never finds a match to boost.  We didn't realize it at the time because the record we were elevating eventually became the top response anyway.
>> Recently added a _val_:formula to the q value to juice records based on a value in the record.
>> Now we have need to push a few other records to the top, but we've lost the ability to use elevate.xml to do it.
>>
>> Tried switching to dismax using qf, pf, qs, ps, and bf with a "pure" q value, and debug showed queryBoost with a match and records, but they weren't moved to the top of the result set.
>>
>> What would really help is if there was something for elevator akin to spellcheck.q like elevation.q so I could pass in the actual user phrase while still performing all the other field score boosts in the q parameter. Alternatively, if anyone can explain why I'm running into problems getting QueryElevationComponent to move the results in a dismax query, I'd be very thankful.
>>
>> -- 
>> Ryan T. Grange
>>
>>      
>
>
>    

Re: QueryElevationComponent blues

Posted by Jon Baer <jo...@gmail.com>.
Maybe some things to try:

* make sure your uniqueKey is string field type (ie if using int it will not work)
* forceElevation to true (if sorting)

- Jon

On Mar 9, 2010, at 12:34 AM, Ryan Grange wrote:

> Using Solr 1.4.
> Was using the standard query handler, but needed the boost by field functionality of qf from dismax.
> So we altered the query to boost certain phrases against a given field.
> We were using QueryElevationComponent ("elevator" from solrconfig.xml) for one particular entry we wanted at the top, but because we aren't using a pure q value, elevator never finds a match to boost.  We didn't realize it at the time because the record we were elevating eventually became the top response anyway.
> Recently added a _val_:formula to the q value to juice records based on a value in the record.
> Now we have need to push a few other records to the top, but we've lost the ability to use elevate.xml to do it.
> 
> Tried switching to dismax using qf, pf, qs, ps, and bf with a "pure" q value, and debug showed queryBoost with a match and records, but they weren't moved to the top of the result set.
> 
> What would really help is if there was something for elevator akin to spellcheck.q like elevation.q so I could pass in the actual user phrase while still performing all the other field score boosts in the q parameter. Alternatively, if anyone can explain why I'm running into problems getting QueryElevationComponent to move the results in a dismax query, I'd be very thankful.
> 
> -- 
> Ryan T. Grange
>