simpler implementation of RiakMap

David Byron dbyron at dbyron.com
Fri Nov 13 19:49:05 EST 2015


As I stare at the code for RiakMap in the riak-java-client 
(https://github.com/basho/riak-java-client/blob/develop/src/main/java/com/basho/riak/client/core/query/crdt/types/RiakMap.java), 
I have the urge for a simpler implementation.

If I'm reading the code right, it looks like it handles a value of each 
RiakDatatype for each key.  As in, it's possible for the same key in a 
map to have all of a counter, map, flag, register and set value.

If it turns out that the underlying data has only one of those, or 
perhaps that I only care about one of those, it feels like

     private final Map<BinaryValue, List<RiakDatatype>> entries =
         new HashMap<BinaryValue, List<RiakDatatype>>();

could become

    private final Map<BinaryValue, RiakDatatype> entries =
         new HashMap<BinaryValue, RiakDatatype>();

What I'm getting at is that the code I'm writing to iterate over the 
elements in a map is doing way more than I'd like.  For a map whose 
values are all registers, I've got something like:

   RiakMap myMap;
   for (BinaryValue key : myMap.view().keySet()) {
     RiakRegister register = myMap.getRegister(key);
   }

which looks clean enough, but is busy under the covers.  I'm really 
whining about the implementation of getRegister and friends:

public RiakRegister getRegister(BinaryValue key)
{
   if (entries.containsKey(key)) {
     for (RiakDatatype dt : entries.get(key)) {
       if (dt.isRegister()) {
         return dt.getAsRegister();
       }
     }
   }
   return null;
}

Because I'm iterating I already know the key is one of the entries, so 
would you consider a patch with an unsafe* (or any other name) set of 
accessors that assumes the key is present?  I could of course call view 
and implement my own method, but I can't see how to take out the loop 
without changing the underlying data structure for entries.

If I'm iterating over lots and lots of keys (i.e. myMap.view().keySet() 
contains lots and lots of elements), it might actually be enough savings 
to notice.  In addition though, I think it's simpler enough to be 
helpful when trying to read/understand the code.

It is of course possible that the underlying data isn't what I expect, 
and contains other data types too.  So a full implementation might need 
hints from the caller about whether to use the more general/existing 
data structure, or the simplified one...and then whether to fail in the 
face of data that doesn't fit in the simplified one, or silently ignore 
it...or ignore it but notify the caller that it's present...and probably 
other stuff I haven't considered yet.

I'd love to hear what you think about all of this.

Thanks much for your help.

-DB




More information about the riak-users mailing list