> It does however allow us to change the n-val after linking the index > to the bucket, so I would wager a guess that this might induce the > same issue we saw before. We will test a bit to confirm when we get > the chance, but I welcome sage advice as to the logic behind this. >
Scratch the above. Error is maintained appropriately. I assume then the only way to change n-vals after the fact is to entirely drop search index, and reindex? Works for me I guess. >> On Tue, Jan 21, 2014 at 1:46 PM, John O'Brien <[email protected]> wrote: >>> >>> Issue: >>> >>> When running searchs against a single dev node cluster, pre-populated >>> with 1000 keys, bitcask backend, search=on and a /search/svan?q=* >>> search URI, the solr response is coming back with three different >>> resultsets, 330 values, the other 354, the other 345. The range of >>> keys 0-1000 are split in no obvious pattern between the 3 result >>> shards.. >>> >>> Anyone have any clue as to what I may have messed up in the config? I >>> assume this is not expected behaviour. >>> >>> Other than that, it works great. ;) >>> >>> Cheers, >>> >>> John >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> >> _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
