|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [jira] [Created] (SOLR-3442) Example schema switch t... JIRA
- [jira] [Commented] (SOLR-3442) Example schema s... Chris Male (JIRA)
- [jira] [Commented] (SOLR-3442) Example schema s... JIRA
- [jira] [Commented] (SOLR-3442) Example schema s... Jack Krupansky (JIRA)
- [jira] [Commented] (SOLR-3442) Example schema s... JIRA
- [jira] [Commented] (SOLR-3442) Example schema s... Jack Krupansky (JIRA)
- [jira] [Commented] (SOLR-3442) Example schema s... Yonik Seeley (JIRA)
- [jira] [Commented] (SOLR-3442) Example schema s... Jack Krupansky (JIRA)
- [jira] [Commented] (SOLR-3442) Example schema s... Jack Krupansky (JIRA)

When I initially read this issue I mistakenly read it as edismax rather than dismax. So, I would request that the intent be crystal clear - is it reasonable to switch the default query parser handler to edismax, or is it being suggested that the more limited dismax query parser be the new default? If the latter, we won't even be able to query specific fields without config changes.
Some of the discussion over on SOLR-2368 might be relevant, as to whether the default query for example should be severely "locked-down" as opposed to highly functional (fields, Lucene syntax, etc.)
I was going to proceed with an edismax-based patch, but now I am not so sure.