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.
rgra...@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
