.nabble.com/Solr-Shard-Strange-results-tp496373p832844.html
Sent from the Solr - User mailing list archive at Nabble.com.
So are we the only ones who never got sharding working with multi-cores?
Bummer... Hopefully someone else will chime in with an answer.
--Tony
--
View this message in context:
http://lucene.472066.n3.nabble.com/Solr-Shard-Strange-results-tp496373p832863.html
Sent from the Solr - User mailing
://www.nabble.com/Solr-Shard---Strange-results-tp23561201p23600878.html
Sent from the Solr - User mailing list archive at Nabble.com.
are weird, or if
it's the top-level combining logic that's causing this.
-Yonik
http://www.lucidimagination.com
--
View this message in context:
http://www.nabble.com/Solr-Shard---Strange-results-tp23561201p23601624.html
Sent from the Solr - User mailing list archive at Nabble.com.
://www.lucidimagination.com
--
View this message in context:
http://www.nabble.com/Solr-Shard---Strange-results-tp23561201p23603031.html
Sent from the Solr - User mailing list archive at Nabble.com.
with multiple search queries, however with some
other search queries, it works fine and returns the proper number for
numFound, and however many doc's there are supposed to be.
Has anyone seen this issue before?
--
View this message in context:
http://www.nabble.com/Solr-Shard---Strange-results
Certainly does seem strange.
Do you have the same uniqueKeyField in both indexes?
Any way you can provide some configuration and some data to reproduce this?
-Yonik
On Fri, May 15, 2009 at 10:40 AM, CB-PO charles.bush...@gmail.com wrote:
Hello,
What we have done is created multiple solr
is happening with multiple search queries, however with some
other search queries, it works fine and returns the proper number for
numFound, and however many doc's there are supposed to be.
Has anyone seen this issue before?
--
View this message in context:
http://www.nabble.com/Solr-Shard
On Fri, May 15, 2009 at 4:11 PM, CB-PO charles.bush...@gmail.com wrote:
Yeah, the first thing I thought of was that perhaps there was something wrong
with the uniqueKey and they were clashing between the indexes, however upon
visual inspection of the data the field we are using as the unique
