Actually, "use raw parser unless query has dismax syntax" approach doesn't
fit, because it kills a lot of useful dismax-related functionality,
described here: http://wiki.apache.org/solr/DisMaxQParserPlugin#Parameters.
However, there is a little cleaner solution than what I originally had in
mind:
On Mon, Feb 27, 2012 at 12:36 PM, Steven A Rowe wrote:
> Separately, do you know about the "raw" query parser[2]? I'm not sure if
> it would help, but you may be able to use it in alternate solution.
>
And explicitly route to edismax when dismax syntax is detected in the
query? That would make
Say, there is an index of business names (fairly short text snippets),
containing: Walmart, Walmart Bakery and Mini Mart. And say we need a query
for 'wal mart' to match all three, with an appropriate ranking order. Also
need 'walmart', 'walmart bakery' and 'bakery' to find the right things in
the
re virtually no repeated
queries in our production logs. Or am I making a bad assumption here, too?
--
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
f they are all in memory
anyway; (b) query caching will have abysmal hit/miss because of the spatial
component; and (c) I misunderstood how query filters work. So, now I'm
thinking a FastLFU query filter cache for non-geo filters.
> Btw, if you need multivalue geofield pls vote for SOLR-2155
&
Hi, all,
I'm new here. Used Solr on a couple of projects before, but didn't need to
dive deep into anything until now. These days, I'm doing a spike for a
"yellow pages" type search server with the following technical requirements:
~10 mln listings in the database. A listing has a name, address,
