> 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
Ryan,
Apologies on the long post delay. We pushed from pre11 to pre20, and
figured out the issue. It looks like we had a mismatch between the
n-val on the bucket, vs the n-val on the seach_index... Pre20 throws
an error telling us to stop being stupid.
It does however allow us to change the n-val
Rob,
The one second wait is because yokozuna is the glue code (putting it very, very
simply) between a Riak cluster and distributed Solr instances. When you write
an object to Riak, yokozuna asynchronously fires off an update to the Solr
service. Solr is, by default, configured to soft commit w
I'm still interested in the question as it applies to Yokozuna. Stable
full-text search in Riak will be very important to my company, so I'd want
to know what the equivalent behaviors are for Yokozuna queries. Do you have
to wait an unspecified amount of time between writing a document and
querying
Hi Rob,
I believe Ryan meant to wait a second to do a Yokozuna search, not a
general Riak K/V operation.
There is more information about "read your own writes" here:
http://basho.com/tag/configurable-behaviors/
--
Luke Bakken
CSE
lbak...@basho.com
On Wed, Jan 22, 2014 at 11:36 AM, Rob Speer wr
> 5. Did you wait at least 1 second before running the queries?
I'm not the original poster but I'm now wondering what this question means.
Under what circumstances do you have to wait 1 second before query results
are available?
We want to always be able to run tests on our database rapidly, wh
John,
1. What did you use to load the data? Do you have a script?
2. What content-type is the data?
3. Do you see any errors in the log directory? Check error.log and solr.log.
4. Do you get any results for the query q=_yz_err:1
5. Did you wait at least 1 second before running the queries?
6.
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
