Re: Split index with Riak 2.0 git (jan 15th) on a single dev node cluster

"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 wrote: > >> 5. Did you wait at least 1 second before running the queries? > > >

Re: Split index with Riak 2.0 git (jan 15th) on a single dev node cluster

> ​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

How long should it take to set bucket properties?

I have objects in buckets that need to be updated based on their previous value. As per the documentation, I've implemented a sibling-resolution strategy that can deal with the writes happening in different orders, and implemented it on the client side. This of course requires me to set "allow_mult

Re: Why does Riak Search find one thing and then tell me there were two?

Sorry, I was actually giving 'rows=10' as the argument, not 'count=10'. That was my mistake in translating between our code and the particular calls to the Riak Python client. It will be hard to reproduce anything further, because by now we have stopped using Riak Search, in favor of just Riak KV

Objects in Riak Search sometimes match based on their old values

I believe this is the same issue reported here: http://riak-users.197444.n3.nabble.com/Issue-on-riak-search-when-update-bucket-tt4026629.html Here's what's happening in my tests: 1. test_riak_10717

Re: "expected_binaries" error in search

=true' That is, I left out a pair of quotation marks, so my document was not a valid JSON document. If I add them in, it works. This was not the same problem I originally encountered, then, because the "expected_binaries" error occurred with correct, programmatically-generated

Re: "expected_binaries" error in search

achine_decision_core.erl"},{line,606}]}, {webmachine_decision_core,decision,1, [{file,"src/webmachine_decision_core.erl"},{line,577}]}]}}mochiweb+webmachine web server On Wed, Apr 17, 2013 at 4:51 PM, Rob Speer wrote: > I reproduced this at the command line. Here I'm storing two docum

Re: "expected_binaries" error in search

I reproduced this at the command line. Here I'm storing two documents, with IDs 'doc8' and 'doc9', into a search-enabled bucket named 'test-search'. # This command works, even though 'lsh' is empty. I believe this is because I've never put a field named 'lsh' in this bucket, 'test-search'. curl -v

Re: Am I misunderstand read and write quorum? Or am I losing writes?

create it as a whole new object. This has to do with the nature > of vector clocks. > > /Erik [not familiar with the Python client API] > > > > -------- Oprindelig meddelelse > Fra: Rob Speer > Dato: > Til: riak-users Users > Emne: Am I misundersta

Am I misunderstand read and write quorum? Or am I losing writes?

My understanding is that if you write a document to a cluster of 4 riak servers with w='quorum', then read from that same cluster with r='quorum', that the read should reflect the result of the right. My understanding is also that, in the Python client (version 5525f4f3, from master), w = r = 'quo

Why does Riak Search find one thing and then tell me there were two?

Today, all my Riak-related tests have been failing. I tracked down the reason why: many calls to riak.solr.search() are returning a 'num_found' that is greater than the actual number of documents they find. Here's an example: >>> riak.solr.search('test_riak-search', 'terms:plasma\|en', count=10)

Re: "expected_binaries" error in search

dbug:start("riak_solr_xml_xform:xform/1 -> return"). > > Then in another window try to index the data. Copy the riak console > output and mail it to me. My guess is something is getting parsed > incorrectly. > > -Z > > > On Tue, Apr 9, 2013 at 12:49 PM, Rob Spe

"expected_binaries" error in search

We're having problems where Riak nodes stop responding to requests, sometimes while trying to add documents and sometimes while trying to delete them. There are a lot of errors in the logs on all machines, and we're wondering if this has something to do with it. A message like this appears every 1

Getting multiple values: is iterating or MapReduce preferred?

I've looked at the archives of this mailing list to find a way to implement a "multi-get" using Riak, for the very common case where there are multiple keys to look up. Making a separate round-trip to the server for each key seems inefficient, after all. I came across the suggestion to use MapRedu

How should I avoid words that are effectively stopwords in Riak Search?

nts. Is there a way to determine, via Riak, which terms are overused so I can remove them from search queries? Or do I need to keep track of this entirely on the client end so I can avoid searching for those terms? Thanks, -- Rob Speer ___