Java client API

Kevin Downey redchin at
Wed Mar 23 17:52:14 EDT 2011

Record or Document are alternatives I'd prefer over Entry (prefixed
with Riak or not)

On Wed, Mar 23, 2011 at 2:25 PM, Jon Brisbin <jon at> wrote:
> On Mar 23, 2011, at 3:21 PM, Kresten Krab Thorup wrote:
> From the client side, the moniker RiakObject is actually not too good.  In
> technical terms, it is of cause a riak_object  - but to a Java programmer,
> it doesn't feel right for it to have that name.  It's more like a
> KeyValueHolder, a RiakEntry (makes you think of Map.Entry), or something
> like that.  I'll vote for calling it RiakEntry, or just plain Entry (we have
> name spaces in Java, you know...)
> I personally don't like using ambiguous short names. I get that you can
> technically distinguish things by package name but using a simple name that
> is very common isn't good for code readability. "RiakEntry" is unambiguous,
> self-documenting, and semantically correct. "Entry" would, in my mind,
> represent a very generic interface that defined various kinds of "Entry"s of
> things.
> It is hard to convey that it is important to get one of these "riak
> objects", update it, and stash it back in there.  I.e. the fact that a
> RiakEntry has the "optimistic concurrency state" (in popular speek) needed
> to later do the update.   One naturally just want to create a new one and
> put into the store; and that aspect should perhaps be hinted in the name of
> this core class, and in the flow of the API.
> Perhaps, for this very reason, store() should be an operation *directly on
> the RiakEntry*; and then guide people by the way these are obtained.
> This feels like a Grails GORM convention. Using finders and calling save
> directly on the object you're working with. I guess it's more a matter of
> personal preference, but I'm not sure I like it as a general rule. It's not
> a very object-oriented approach, either, as it mixes concerns a little too
> much, in my mind.
>     RiakClient renamed to Riak
>     RiakObject renamed to Entry
> IMHO the name "Riak" for a client doesn't feel semantically correct to me.
> Its also a little ambiguous. It's a Riak what? "Riak" the noun refers to the
> server, not a client which can connect to it.
> While I don't agree with dropping the Riak part of RiakEntry, I do think the
> name "entry" is consistently used in the Riak docs and should be carried
> over rather than use the more ambiguous term "Object".
>     Bucket b = c.get("people");
> Again there's the issue of mixing concerns. Does the helper class describe a
> resource or operate on the resource? In this case it does both. Just not
> sure everyone feels the same about compressing these together. Dynamic
> language fans might like this approach because it's results in less "stuff"
> overall to keep track of. OO folks, though, might not feel comfortable with
> that paradigm.
> Whichever approach you end up choosing someone's going to hate anyway and
> tell you you should have picked the other one. ;)
> Truth be told, I'm not a die-hard OO fan. I'd rather use Erlang or Haskell
> if I could!
> Thanks!
> Jon Brisbin
> Twitter: @j_brisbin
>     // example 1
>     Entry e = b.get("russelb");   // does GET /riak/people/russeldb
>     e.set("application/json", "{ name: \"Russel Brown\" }" );
> Then, have a special method to create new entries:
>     // example 2
>     Entry e2 = b.create("krab");     // does not issue GET /riak/people/krab
>     b.set("Kresten Krab Thorup"); // implies text/plain;charset=utf-8
> The latter (example 2) would issue a "PUT" w/no vector clock; whereas the
> former (example 1) automatically grabs the vector clock from the GET.  If
> you sure Bucket.get("no-such-key") then the only "harm done" is that you
> spent an extra round trip to the server trying to find the VC for
> no-such-key.
> In fluent style, this would be
>     c.getBucket("people").get("krab").set("Kresten Crap Throwup").store();
>     // and/or
>     c.get("people", "krab").set("XXX").store();
> Which captures the flow that the vector clock needs to be there for the
> store.
> Likewise, this will make it much more sound to delete things, because you
> also need the entry (includin gth VC) to delete an object properly
> bucket.get("krab").delete()
> makes a lot more sense than
>        bucket.create("krab").delete()
> WHICH IS GREAT!  Because we want people to pass in VC to delete operations
> ... those should really also be replayable, which I am sure they will be one
> day :-)
> Kresten
> On Mar 23, 2011, at 11:05 , Russell Brown wrote:
> Hi,
> I'm trying to make the Java client easier to use and less tied to underlying
> implementation so I've started designing a new API.
> I've put some interfaces up
> at
> I'd really appreciate any comments you may have.
> My intention is to adapt the existing client(s) to these interfaces and
> deprecate the old client API gradually (so there will be backward
> compatibility for a few releases.) I'll also be reusing the existing client
> implementations underneath the API, this isn't a wholesale re-write.
> I hope you can take some time to let me know what you think. I'll put my
> thickest skin on.
> Many thanks
> Russell
> PS It is all maven'd up so just clone and mvn eclipse:eclipse if you want to
> get a good look.
> <ATT00001..txt>
> _______________________________________________
> riak-users mailing list
> riak-users at
> _______________________________________________
> riak-users mailing list
> riak-users at

And what is good, Phaedrus,
And what is not good—
Need we ask anyone to tell us these things?

More information about the riak-users mailing list