dismax and field indicators

[WHIRLYCOTT <ph...@whirlycott.com>]

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
                                    phil@whirlycott.com
                                    http://www.whirlycott.com/phil/

Re: dismax and field indicators

[Chris Hostetter <ho...@fucit.org>]

: 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

Re: dismax and field indicators

[Yonik Seeley <yo...@apache.org>]

On 8/16/06, Chris Hostetter <ho...@fucit.org> 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

Re: dismax and field indicators

[Chris Hostetter <ho...@fucit.org>]

: 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