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@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
