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 <gints.gaili...@gmail.com>wrote:
> 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 second vclock is now out of date too, at that moment, since the
> first delete already updated the object. If that's correct, then scratch 2)
> off the list.
>
> Then the only question left is 1) siblings in map reduce - how do I access
> them?
>
> Thanks,
> Gints
>
>
>
> On Mon, Sep 23, 2013 at 8:26 PM, Gints Gailītis
> <gints.gaili...@gmail.com>wrote:
>
>> 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 map reduce query? I assumed
>> that there would simply be more elements in the values array, but it seems
>> that this is not the case. Basically, the beginning of my javascript map
>> function looks something like this:
>> function(param) {
>> for ( var i=0; i < param.values.length; i++ ) {
>> ... do stuff with param.values[i] ...
>>
>> but this does not seem to let me access all the siblings (or I might have
>> screwed something up elsewhere in my code, of course).
>>
>> Is this how siblings should be handled in map reduce? If not, how?
>>
>> 2) Now I'm running into another issue where even a simple find by key
>> seems to act weird.
>>
>> When I PUT the object for the first time, I get this vclock:
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCUy5rEyzHy95TRfFgA=
>>
>> Then I read the object, and get the same vclock back:
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCUy5rEyzHy95TRfFgA=
>>
>> Then, I modify it, PUT it again, and get a new vclock:
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCUy5bEyzHy95TRfFgA=
>>
>> Then, I do two deletes, one with each of the vlocks:
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCUy5rEyzHy95TRfFgA=
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCUy5bEyzHy95TRfFgA=
>>
>> Then, I do another read, and I get a 300 response with 3 siblings, two
>> marked X-Riak-Deleted and a third one whose value matches the second PUT.
>> The vclock I get along with the 300 response is:
>> a85hYGBgzGDKBVIcypz/fgZJFyllMCWy5LEyzHy95TRfFgA=
>>
>> (Full packet capture, including the setup of the bucket attached).
>>
>> Why does Riak create the third sibling? All I've basically done is
>> created a new object, modified it, and then deleted it, once with a stale
>> vclock, once with the latest vclock.
>>
>>
>>
>>
>> On Mon, Sep 23, 2013 at 7:19 PM, Brady Wetherington <br...@bespincorp.com
>> > wrote:
>>
>>> 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 <gints.gaili...@gmail.com> wrote:
>>>
>>>> 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 -> Uy5bEy)
>>>>
>>>> Then, I did a DELETE, using the first vector clock, not the second,
>>>> updated
>>>> one.
>>>>
>>>> After that the object was gone, I could not find it in the database any
>>>> more.
>>>>
>>>> Is this supposed to be like that - deleting an object providing a stale
>>>> vclock actually deletes it? Or am I probably doing something wrong?
>>>>
>>>> Thanks,
>>>> Gints
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://riak-users.197444.n3.nabble.com/DELETE-and-vclocks-tp4029176.html
>>>> Sent from the Riak Users mailing list archive at Nabble.com.
>>>>
>>>> _______________________________________________
>>>> riak-users mailing list
>>>> riak-users@lists.basho.com
>>>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>>>>
>>>
>>>
>>
>
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
