In 1.3 (trunk, dev build), the query parsing has been extracted into a
component. It shoudl be easy to replace just query parsing component
and keep the rest of the chain the same.
I'm not quite following why it is a problem to have two urls for
dismax vs standard query. Dismax expects unescapped user queries
while standard requires valid lucene query syntax. Is your problem
that you want a HTML form to hit a single URL for either case?
ryan
On Apr 26, 2008, at 1:33 AM, David Smiley @MITRE.org wrote:
I am frustrated that I have to pick between the two because I want
both. The
way I look at it, there should be a more configurable query handler
which
allows me to dimax if I want to, and pick a parser for the user's
query
(like the flexible one used by the standard query handler, or the more
restrictive one found in DisMax Q.H. today). At the moment, I'm
faced with
telling a user of my search service (another developer of a
corporate app
using my corporate search service) that he has to compose a dis-max
manually
(i.e. use the standard query handler to get the job done) simply
because he
wants to do a prefix query (which isn't supported by DisMax Q.H.).
This is
for an auto-complete type thing, by the way. You might argue it's
not hard
-- that's true though it is annoying. But the bigger issue is that
I can't
encapsulate these internal details into my search service -- where it
belongs IMO.
~ David Smiley
hossman_lucene wrote:
: Is the main difference between the StandardQueryHandler and
: DisMaxQueryHandler the supported query syntax (and different query
: parser used in each of them), and the fact that the latter creates
: DisjunctionMaxQueries, while the former just creates vanilla
: BooleanQueries? Are there any other differences?
the main differnece is the query string yes: Standard expects to get
"lucene QueryParser" formatted queries, while DisMax expects to get
raw
user input strings ... Standard builds queries (wehter they be
prefix or
boolean or wildcard) using the QueryParser as is, while DisMax does a
"cross product" of the user input across many differnet fields and
builds
up a very specific query structure -- which can then be augmented
with
aditional query clauses like the "bq" boost query and the "bf" boost
function.
there's no reason the StandardRequestHandler can't construct
DisMaxQueries
(once QueryParser has some syntax for them) and
DisMaxRequestHandler does
(at the outermost level) generate a BooleanQuery (with a custom
"minShouldMatch" value set on it) but the main differnece is really
the
use case: if you want the clinet to specify the exact query
structure that
they want, use StandardRequstHandler. if you want the client to just
propogate the raw search string typed by the user, without any
structure
or escaping, and get the nice complex DisMax style query across the
configured fields, the DisMax handler was written to fill that niche.
(load up the example configs, and take a look at the query toString
from
this url to see what i mean about the complex structure...
http://localhost:8983/solr/select/?qt=dismax&q=how+now+brown+cow&debugQuery=1
-Hoss
--
View this message in context:
http://www.nabble.com/Standard-vs.-DisMaxQueryHandler-tp6421205p16909626.html
Sent from the Solr - User mailing list archive at Nabble.com.