I did a PUT, and the vclock that came back was:
a85hYGBgzGDKBVIcypz/fgZJFylnMCUy5rEyNOdtOc2XBQA=
Then I read the object back, modified it, and PUT it again, providing the
old vclock, and got a new vclock:
a85hYGBgzGDKBVIcypz/fgZJFylnMCUy5bEyNOdtOc2XBQA=
(Notice they are slightly different: Uy5rEy
Well, I'm not sure, and I'm new to Riak too, but I *think* you'd need to
set allow_multi on the bucket.
-B.
On Mon, Sep 23, 2013 at 4:01 AM, Gints wrote:
> I did a PUT, and the vclock that came back was:
> a85hYGBgzGDKBVIcypz/fgZJFylnMCUy5rEyNOdtOc2XBQA=
>
> Then I read the object back, modifi
Sure enough, I had a break; where a continue; should be in my map reduce
loop, which caused me to lose some siblings. Meh, all is fine now, sorry for
the spam it's been a long day :)
--
View this message in context:
http://riak-users.197444.n3.nabble.com/DELETE-and-vclocks-tp4029176p4029180.htm
Sure enough, I had a break; where a continue; should be in my map function
loop, which caused me to lose some siblings. Meh, all is fine now, sorry
for the spam - it's been a long day :)
On Mon, Sep 23, 2013 at 8:43 PM, Gints Gailītis wrote:
> Oh, OK, I think I just got it - the third sibling is
Sorry, should have mentioned that, I do set allow_mult=true.
Also, it seems I had a problem with my initial test - what was failing to
find the object was my map reduce query, a simple find by key worked just
fine. But now there seem to be two issues:
1) How does Riak handle siblings when doing a
Oh, OK, I think I just got it - the third sibling is created because a
DELETE with the stale vclock is internally the same as a write with a stale
vclock, so sibling resolution potentially needs to take place after I
delete it for the first time, and then, when I delete it for the second
time, that
On September 23, 2013 12:41:04 PM Matt Black wrote:
> Hey list.
>
> A quick question on best practices really:
>
>- Should I use a bin index with ISO8601 format?
>- Or should I use an Unix timestamp as an integer index?
>- Is there likely to be a performance difference? (There will ce
Hi Matt,
I've asked around and there doesn't seem to be much of a performance
difference between the two. Unix timestamps were recommended due to
the simplicity of doing range queries (like Matthew Dawson suggested)
as well as storage size. Just use UTC and you'll be set.
--
Luke Bakken
CSE
lbak..
Hi,
I am following the directions for configuring Riak with Riak-CS.
http://docs.basho.com/riakcs/latest/cookbooks/configuration/Configuring-Riak/
When I follow the directions, riak console gives a problem when
starting:
22:43:33.174 [error] Load
Hello -
Sounds like you have an older version of Erlang trying to load code compiled
with a newer version of Erlang.
Cheers,
Dave
> On Sep 23, 2013, at 10:48 PM, Darren Govoni wrote:
>
> Hi,
> I am following the directions for configuring Riak with Riak-CS.
>
> http://docs.basho.com/riakcs
I had the same issue, when I straced the beam i saw a very high number of
read/write to entropy files, I just disabled the entropy in configuration
file app.config:
%% Enable active anti-entropy subsystem + optional debug
messages:
%% {anti_entropy, {on|off, []}},
Hi,
I am trying to run the following mapreduce query across my cluster:
# curl -XPOST http://10.179.229.209:8098/mapred -H "Content-Type:
application/json" -d '{"inputs":"tweets",
"query":[{"map":{"language":"javascript", "source":"function(value,
keyData, arg) {t = JSON.parse(value.values[0].dat
Am 24.09.13 07:03, schrieb xsanch:
> I had the same issue, when I straced the beam i saw a very high number of
> read/write to entropy files, I just disabled the entropy in configuration
> file app.config:
>
> %% Enable active anti-entropy subsystem + optional debug
> messages:
>
13 matches
Mail list logo
