> On 20 Aug 2015, at 18:54, Timur Fayruzov <timur.fairu...@gmail.com> wrote: > > Forgot to include the list in the initial response. > > On Thu, Aug 20, 2015 at 12:31 AM, Russell Brown <russell.br...@me.com> 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?
I guess. > > 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”. I’m pretty sure the API returns not_found. I still don’t fully understand what application logic would need to differentiate between zero and not_found for a counter, and not_found and the empty set for a set. > > 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. I guess it is, yes. > > On 20 Aug 2015, at 01:59, Timur Fayruzov <timur.fairu...@gmail.com> 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
