[
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: [email protected]
For additional commands, e-mail: [email protected]
