On 29 Mar 2011, at 10:02, Kresten Krab Thorup wrote:
> One thing, which is often missed by newcomers to Riak [I'm not saying you
> missed it], is the importance of managing client IDs, and passing the right
> vector clocks back to the server.
>
> { Basho'ers ... please corret me if I'm wrong }
Not wrong, very right.
>
> The above two things (1.a and 1.b) are so difficult to understand for
> newcomers, and a bit tricky to get right, so IMHO a new Java client should
> provide some way to avoid doing these mistakes as the default behavior.
>
> - So, it should choose a good client ID fo you if you don't.
> - And it should make it so that you can't do UPDATE/PUT without having first
> GOT'en the riak object.
>
>
> I.e. NOT EXPOSE constructors for the implementors of RiakObject. The only
> way to get an UpdateableRiakObject is to call RiakClient.get, or as the
> result of calling update/create; you can't just allocate one. Also calling
> update/create should "invalidate" the original object so that it cannot
> accidentally be used again.
>
> I really think we need to have a way to enforce the linear nature of these
> things. Otherwise people get fooled.
>
I'm working on this now, thanks to some ideas from Coda Hale at Yammer. The
concept is that a store *requires* a ConflictResolver and a Mutation. Any PUT
is in fact
get
[convert to domain representation]
resolve conflicts
mutate
[convert]
put
[return new object]
Hence 2 APIs, a low level for the transport business of talking to riak
(REST/protocol buffers/etc) and a high level one for dealing with riak's
implications. I am getting there and hope to have an example to show very soon.
>
>
> Kresten
>
>
>
>
> _______________________________________________
> 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
