simpler implementation of RiakMap

Alex Moore amoore at basho.com
Tue Nov 17 00:14:00 EST 2015


Hey David,

So with the CRDT Map implementation, you can have a register, a counter, an
inner map, a set, and a flag embedded within a map, all with the same name
(oh my!).

In the underlying API the map entry identifier is actually made of both the
name and the type, so you can pull off that bit of trickery.  You can see
this bleed through a little bit in the HTTP JSON API, where map field id's
are represented as <name>_<type> :

curl -XPOST http://localhost:8098/types/maps/buckets/customers/datatypes/ahmed_info
\ -H "Content-Type: application/json" \ -d ' { "update": {
"annika_info_map": { "update": { "first_name_register": "Annika",
"last_name_register": "Weiss", "phone_number_register": "5559876543" } } }
} '

Also since the API's been out for awhile now, doing the changes you listed
could break compatibility with other clients / users :-/

I'll take a look at getRegister and friends, and see if there's a better
way to implement them though.

Thanks,
Alex

On Fri, Nov 13, 2015 at 7:49 PM, David Byron <dbyron at dbyron.com> wrote:

> 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
>
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20151117/953d918c/attachment-0002.html>


More information about the riak-users mailing list