Default values vs non-existing keys for CRDTs

2015-08-19 Thread Timur Fayruzov
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 holds 0. Now, if I put counter with value 0 at this
key and run the query, I get the same result. Is there any way to
distinguish between these two different states?

Note: when working with sets there is a context that I can check. If I
fetch a set and the context is null, it means that the set does not exist
under this key. This trick does not work for counters though, as they do
not maintain context. Is it a valid trick to use though?

I posted this to StackOverflow a while ago, but no luck:
http://stackoverflow.com/questions/31845164/riak-dataypes-default-values-vs-non-existing-keys

Thanks,

Timur
___
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


Re: Default values vs non-existing keys for CRDTs

2015-08-20 Thread Timur Fayruzov
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(fetchOp)
res.isNotFound should equal(true)

But also means that I need to issue a separate (albeit lightweight) request
to check whether the key exists before fetching a CRDT value. I'm also not
entirely sure whether it is compatible with CRDT, based on the Russel's
comment below.

On Wed, Aug 19, 2015 at 8:48 PM, Dmitri Zagidulin 
wrote:

> 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 result of trying to access an existing key (with a
> value set to 0):
>
> curl
> http://localhost:8098/types/counters/buckets/room_occupancy/datatypes/room-215
> {"type":"counter","value":0}
>
> And here's the result of retrieving the value of a non-existent key:
>
> curl
> http://localhost:8098/types/counters/buckets/room_occupancy/datatypes/non-existent-room
> {"type":"counter","error":"notfound"}
>
> There's a workaround you can do with your existing client, however (until
> the issue with the FetchCounter request gets fixed).
>
> You can issue a regular Fetch Object operation (preferably setting the
> 'HEAD only' option to true) for that counter. A Riak counter (or any other
> data type) still exists as a regular object, and you can issue a HEAD
> request to it (as opposed to a Fetch Counter or whatever), and it'll return
> a 404 as expected.
>
> On Wed, Aug 19, 2015 at 8:59 PM, Timur Fayruzov 
> wrote:
>
>> 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 holds 0. Now, if I put counter with value 0 at
>> this key and run the query, I get the same result. Is there any way to
>> distinguish between these two different states?
>>
>> Note: when working with sets there is a context that I can check. If I
>> fetch a set and the context is null, it means that the set does not exist
>> under this key. This trick does not work for counters though, as they do
>> not maintain context. Is it a valid trick to use though?
>>
>> I posted this to StackOverflow a while ago, but no luck:
>> http://stackoverflow.com/questions/31845164/riak-dataypes-default-values-vs-non-existing-keys
>>
>> Thanks,
>>
>> Timur
>>
>> ___
>> 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


Re: Default values vs non-existing keys for CRDTs

2015-08-20 Thread Timur Fayruzov
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 bottom value until you operate on them.
>
>
Thanks, Russell. I was under impression that key mechanism does not differ
between 'regular' KV store and CRDT, that is checking key existence does
not involve CRDT concepts. Is that not true?

>
>
>> Since you cannot do a compare-and-set operation with a counter anyway
>> (that is you can’t “put counter with value 0” at that key), why do you need
>> to distinguish between 0 as bottom and 0 as value?
>
>
I'm building a Scala wrapper for our services to use and trying to provide
a uniform simple interface for CRDT counters and sets (maps are a whole
different story). One of the fundamental operations is to be able to tell
whether a key exists in the store. Although it's not possible to 'set'
counter to 0, update '+1' followed by update '-1' at 'key' will result in
'key' with value 0, which is semantically different from answer "no 'key'
found".

Could you also comment whether null context for a set is a valid way to
tell that set did not exist in store? It feels hacky.

On 20 Aug 2015, at 01:59, Timur Fayruzov  wrote:
>
> > 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 holds 0. Now, if I put counter with value 0 at
> this key and run the query, I get the same result. Is there any way to
> distinguish between these two different states?
> >
> > Note: when working with sets there is a context that I can check. If I
> fetch a set and the context is null, it means that the set does not exist
> under this key. This trick does not work for counters though, as they do
> not maintain context. Is it a valid trick to use though?
> >
> > I posted this to StackOverflow a while ago, but no luck:
> http://stackoverflow.com/questions/31845164/riak-dataypes-default-values-vs-non-existing-keys
> >
> > Thanks,
> >
> > Timur
> >
> > ___
> > 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


Forming inputs to MR job

2015-12-30 Thread Timur Fayruzov
Hello,

I'm trying to write a simple MR job using Javascript and hit a wall right
at start. I can't figure out how to specify "inputs". Here's the code:
curl -XPOST "my_riak_server:8098/mapred" -H "Content-Type:
application/json" -d @-