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 Fri, 03 Feb 2012 21:50:54 GMT

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

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

bq. If/when eDismax can be configured to fill the original role of DisMax, why should we maintain
the old one?

my chief concerns -- as i mentioned -- are that _currently_ edismax has behavior dismax doesn't
support that people may actively *not* want, and that edismax may have quirks dismax doesn't
that we have yet to discover and don't realize because the overall test coverage is low and
the EDismaxQParse is so much more significantly complex and there are so many weird edge cases.

But sure: if SOLR-3086 makes it possible to configure EDisMaxQParser to behave the same as
DisMaxQParser, and if we feel confident through testing that (when configured as such) they
behave the same, i've won't have any objections what soever to retiring the DisMaxQParser
class for simplifying code maintence.

bq. Personally I don't think we should worry about the added features after edismax becomes
dismax.

this part i don't understand ... even if all of the functionality ultimately merges and only
the EDisMaxQparser remains, why should defType=dismax and defType=edismax suddenly become
the smae thing?  why not offer two instances by default, "edismax" which is open and everything
defaults to on, and "dismax" where it's more locked down like it is today?  ... what is gained
by changing the default behavior when people use "defType=dismax"?  

(as i said before (in a slightly diff way above): would you suggest that defType=lucene should
now be an EDisMaxQparser instance as well? with a CHANGES.txt note telling people that if
they only want features LuceneQParser supported, they have to add invariant params to disable
them????)

                
> 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