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 <[email protected]> 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 > > 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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
