> On 20 Aug 2015, at 18:54, Timur Fayruzov wrote:
>
> Forgot to include the list in the initial response.
>
> On Thu, Aug 20, 2015 at 12:31 AM, Russell Brown wrote:
> It’s a tricky one Timur. CRDTs are based on Join Semi-Lattices, and they have
> the concept of a bottom value. That is what y
Forgot to include the list in the initial response.
> On Thu, Aug 20, 2015 at 12:31 AM, Russell Brown
> wrote:
>
>> It’s a tricky one Timur. CRDTs are based on Join Semi-Lattices, and they
>> have the concept of a bottom value. That is what you are seeing. Implicitly
>> all keys exist at the bo
Forgot to include the list in the initial response.
Thanks, Dmitri. I'm writing in Scala so I use riak java client. That seem
to make the trick:
val fetchOp = new
FetchValue.Builder(key.location).withOption(FetchValue.Option.HEAD,
java.lang.Boolean.TRUE).build()
val res = module.client.execute(f
It’s a tricky one Timur. CRDTs are based on Join Semi-Lattices, and they have
the concept of a bottom value. That is what you are seeing. Implicitly all keys
exist at the bottom value until you operate on them. Since you cannot do a
compare-and-set operation with a counter anyway (that is you ca
>From what I understand, this is a limitation of that particular client
(what language is that, by the way?). Feel free to open an issue on Github
for it.
The HTTP API, at least, does distinguish between a non-existent counter and
a counter whose value happens to be 0.
For example, here's the res
Hello,
It seems that Riak Datatype API does not allow to distinguish between
non-existing keys and default values. For example, if I query for
non-existing key as follows:
val fetchOp = new FetchCounter.Builder(key).build()
val c = client.execute(fetchOp).getDatatype
I'll get a counter that hold
