lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2368) Improve extended dismax (edismax) parser
Date Wed, 01 Feb 2012 23:53:53 GMT

    [ https://issues.apache.org/jira/browse/SOLR-2368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13198340#comment-13198340
] 

Hoss Man commented on SOLR-2368:
--------------------------------

bq. are there any blockers left for retiring the old dismax parser?

As i've mentioned before, I don't think DismaxQParser should ever be retired ... i'm still
not convinced that the (default) parser you get when using "defType=dismax" should change
to ExtendedDismaxQParser instance

My three main reasons for (still) feeling this way are:
* I see no advantage to changing what QParser you get (by default) when asking for "dismax"
... not when it's so easy for new users (or old users who want to switch) to just use "edismax"
by name. (or explicitly declare their own instance of ExtendedDismaxQParser with the name
"dismax" if that's what they always want)
* ExtendedDismaxQParser is a significantly more complex beast then DismaxQParser, and likely
to have a lot of little quirks (and bugs) that no one has really noticed yet.  For people
who are happy with DismaxQParser, we should leave well enough alone.
* Even with things like SOLR-3026 allowing you to disable field specific queries, ExtendedDismaxQParser
still supports more types of queries/syntax then DismaxQParser (ie: fuzzy queries, prefix
queries, wildcard queries, etc...) which may have performance impacts on existing dismax users,
many of whom probably don't want to start allowing from their users -- particularly considering
that limited syntax w/o metacharacters was a major advertised advantage of using dismax from
day 1.

Please note: i have no tangible objection to smiley's suggestion that...

bq. defType should default to ... [edismax] in Solr 4

...if folks think that the ExtendedDismaxQParser would make a better default then the LuceneQParser
moving forward, i've got no objection to that -- but if someone explicitly asks for "defType=dismax"
by name, that should be the DismaxQParser (and it's limited syntax) ... ExtendedDismaxQParser
is a completely different animal.  

saying defType=dismax should return an ExtendedDismaxQParser makes as much sense to me as
saying that defType=lucene should return an ExtendedDismaxQParser -- just because the legal
syntax of edismax is a super set of dismax/lucene doesn't mean they are equivalent or that
we should assume "it's better" for people who ask for a specific QParser by name.
                
> Improve extended dismax (edismax) parser
> ----------------------------------------
>
>                 Key: SOLR-2368
>                 URL: https://issues.apache.org/jira/browse/SOLR-2368
>             Project: Solr
>          Issue Type: Improvement
>          Components: search
>            Reporter: Yonik Seeley
>              Labels: QueryParser
>
> This is a "mother" issue to track further improvements for eDismax parser.
> The goal is to be able to deprecate and remove the old dismax once edismax satisfies
all usecases of dismax.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message