Here is one potential design approach:
1. Create a single collection (instead of two collections).
Let your schema have a "RecordType" field which can take the values of
either "initial" or "follow-up" for documents that are indexed into this
collection.
2. Let there be 30 shards - just like you
Try adding &debug=all to the query and see what the parsed form of the query
is, likely you're
1> using phrase queries, so "broadway hotel" requires both words in the text
or
2> if you're not using phrases, you're searching for the AND of the two
terms.
But debug=all will show you.
Plus, take a l
Please ignore my earlier answer .. I had missed that you wanted a match
spotting .. So that all the indexed terms must be present in the query ...
One way, I can think of is SpanQueries .. But it won't be efficient and
won't scale to multiple fields ..
My suggestion would be to keep the mapping
*Span Queries for illustration :*
During Analysis : Inject startSentinel and endSentinal in your indexed
field ..
So after analysis your field will look like ...
abc def
Now during query time, you can expand your query clause programmatic create
queries which will look like
( xyz ) OR (
I have figured it out.
The reason is simply the type of join in Solr. It is an outer join. Since
both filter queries are executed separately, a house that has available
documents with discount > 1 or (sd_year:2014 AND sd_month:11) will be
returned even though my intention was applying bother cond
I wonder if AnalyzingInfixSuggester could be useful as an alternative
way to approach that issue. See a quick write-up and links at:
http://blog.mikemccandless.com/2014/01/finding-long-tail-suggestions-using.html
Regards,
Alex.
Personal: http://www.outerthoughts.com/ and @arafalov
Solr resource
