dismax and field indicators

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

dismax and field indicators

WHIRLYCOTT
When I'm using a dismax query handler, I'm having trouble doing  
queries like this:

        category:fruit apple

        ... or...
       
        category:computers apple

The dimax query handler docs (http://wiki.apache.org/solr/ 
DisMaxRequestHandler) make reference to special chars being escaped,  
so I'm wondering if the ':' qualifier is being made into something  
useless.

My queries work when using the 'standard' qt.

Thoughts?

phil.

--
                                    Whirlycott
                                    Philip Jacob
                                    [hidden email]
                                    http://www.whirlycott.com/phil/


Reply | Threaded
Open this post in threaded view
|

Re: dismax and field indicators

Chris Hostetter-3

: When I'm using a dismax query handler, I'm having trouble doing
: queries like this:
:
: category:fruit apple

: The dimax query handler docs (http://wiki.apache.org/solr/
: DisMaxRequestHandler) make reference to special chars being escaped,
: so I'm wondering if the ':' qualifier is being made into something
: useless.

yeah ... the dismax handler is designed this way -- it doesn't support the
full syntax of the lucene QueryParser, instead it treats the text input as
literal text the user is searching for, and looks for it across all of the
fields configured in the qf.

If your goal is to search for "apple" and restrict the results to things
in the category "fruit" then you can use the fq (Filter Query) param to
specify a regular QueryParser like query to define a super set of all
legal results (ie:  "qt=dismax&q=apple&fq=category:fruit") ... this has
two benefits over doing the same type of thing with StandardRequest
handler:
  1) The tf of the Term category:fruit doesn't affect the scores of
     results, they are judged entirely on the merrit of the word "apple"
  2) The fq is used to build a DocSet which is cached, so the next time
     you do a query with teh same restriction
     (ie: "qt=dismax&q=banana&fq=category:fruit") only the "banana" part
     of your query needs to be computed.

If your goal is to search for "apple" and have items in the result which
match category:fruit get better scores then items which don't, then use
the bq (Boost Query) param in the same way as the fq param above ...
again, the full lucene QueryParser syntax is supported.



-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: dismax and field indicators

Yonik Seeley-2
On 8/16/06, Chris Hostetter <[hidden email]> wrote:
> yeah ... the dismax handler is designed this way -- it doesn't support the
> full syntax of the lucene QueryParser, instead it treats the text input as
> literal text the user is searching for,

I think there is value in this type of feature...
A search-box is a very common thing, and providing a way for the
front-end to easily query solr without worrying about the format of
the query (escaping special chars, making sure it's well formed, etc)
is something that it seems like the standard request handler could
also benefit from.

Maybe a "uq" parameter?  (for user query, or unstructured query)

-Yonik
Reply | Threaded
Open this post in threaded view
|

Re: dismax and field indicators

Chris Hostetter-3
: I think there is value in this type of feature...
: A search-box is a very common thing, and providing a way for the
: front-end to easily query solr without worrying about the format of
: the query (escaping special chars, making sure it's well formed, etc)
: is something that it seems like the standard request handler could
: also benefit from.
:
: Maybe a "uq" parameter?  (for user query, or unstructured query)

maybe .. but I *think* this can already be achieved using the dismax
handler with a qf containing only the defaultSearchField, and no fq, bq,
bf, or pf params.  (I'm not 100 percent certain that it's functionally
equivilent to what you are describing -- but i'm pretty sure)

Heck, since the dismax handler is pretty much useless without *something*
in the qf (either in the config or in the url)  we could cahnge the
default behavior of dismax to use the defaultSearchField when the qf is
empty.

If we really want to cahnge the StandardRequestHandler to support this,
then instead of adding a new param, it might make more sense to make the
"Query Parser" more configurable via init/query params and reflection (or
something) ... then the "q" param can either be Lucene syntax (by default)
or "user syntax" (using something like the current DisMaxQueryMarser), or
even surround -- all depending on what your config looks like.




-Hoss