: What would be the scope of the work to implement Erik's suggestion, I
: would have to ask my boss, but I think we would then contribute the code
: back to Solr.
The QParser modifications would be fairly straight forward -- adding some
setters to SolrQueryParser to set booleans telling when to use it's
superclasses behavior by default, and when to use it's "filter" based
approaches for prefixes, wildcards, and range queries. then add request
param checks to LuceneQParserPlugin to decide when/if to call those
setters...
: This should probably be continued on solr-dev, right?
...or in this issue...
https://issues.apache.org/jira/browse/SOLR-218
...but this still wouldn't address the core risk that using the non-Filter
based versions might cause TooManyClauses (or OOM if you set the clause
limit really high) ... hence Mark's comment that ultimately the *right*
thing to do is find a way to make all of these ConstantScore queries play
nicely with the highlighter ... which is a discussion for [EMAIL PROTECTED]
: Am Mittwoch, den 17.09.2008, 17:19 -0400 schrieb Mark Miller:
: > Alas no, the queryparser now uses an unhighlightable constantscore
: > query. I'd personally like to make it work at the Lucene level, but not
: > sure how thats going to proceed. The tradeoff is that you won't have max
: > boolean clause issues and wildcard searches should be faster. It is a
: > bummer though.
-Hoss
