You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a semantic difference between non-existing key and a default value may me important for downstream consumers. However, CRDT queries return default values: 0 for a counter and empty set for a set. My following examples are in Scala:
val fetchOp = new FetchCounter.Builder(location).build()
val c = client.execute(fetchOp).getDatatype // if I get 0, does the key exist in store?
For counters, there is a workaround that involves an additional query:
val fetchOp = new FetchValue.Builder(location).withOption(FetchValue.Option.HEAD, java.lang.Boolean.TRUE).build()
val res = client.execute(fetchOp) // res.isNotFound should equal(true).
// Why isNotFound not supported by CRDTs?
For sets, there seem to be a hack that a context object should be null if set did not exist before (not sure if it's a valid way though).
The concept of non-existing key is important enough to support it explicitly (like with regular objects in the snippet above).
There is a semantic difference between non-existing key and a default value may me important for downstream consumers. However, CRDT queries return default values: 0 for a counter and empty set for a set. My following examples are in Scala:
For counters, there is a workaround that involves an additional query:
For sets, there seem to be a hack that a context object should be null if set did not exist before (not sure if it's a valid way though).
The concept of non-existing key is important enough to support it explicitly (like with regular objects in the snippet above).