Java client API

Jon Brisbin jon at jbrisbin.com
Wed Mar 23 17:25:58 EDT 2011


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

http://jbrisbin.com
Twitter: @j_brisbin



> 
>     // example 1
>     Entry e = b.get("russelb");   // does GET /riak/people/russeldb
>     e.set("application/json", "{ name: \"Russel Brown\" }" );
>     e.store();
> 
> 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
>     b.store();
> 
> 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 https://github.com/russelldb/riak-java-client-api
>> 
>> 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 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/20110323/433be12c/attachment.html>


More information about the riak-users mailing list