I'm sure Roach will correct me if I'm off-base, but I believe the store operation does a fetch and resolve before writing. I think the ideal way to do that is to create a Mutation<T> (T being your POJO) as well, in which case it's less of a "store" and more of a "fetch-modify-write". The way to skip the fetch/modify is to use the withoutFetch() option on the operation builder.
On Sat, Aug 10, 2013 at 6:50 PM, Matt Painter <[email protected]> wrote: > Hi, > > I've just rolled up my sleeves and have started to make my application > more robust with conflict resolution. > > I am currently using a @RiakVClock in my POJO (I need to think more about > whether the read/modify/write approach is preferable or whether I'd have to > rearchitect things). > > I read in the Riak Handbook the recommendation that conflicts are best > resolved on read - not write - however the example App.java snipping on > the Storing data in > Riak<https://github.com/basho/riak-java-client/wiki/Storing-data-in-riak#appjava> > page > in the Java client's doco uses a resolver on both the store() and > fetch()operations. > > Indeed, if I don't specify my conflict resolver in my store(), things > blow up (in my unit test, mind - I'm still getting my head around the whole > area so my test may be a bit contrived). > > However when I use it in both places, my conflicts are being resolved > twice. Is this anticipated? > > My store is: > > bucket.store(record).returnBody(true). > withoutFetch().withResolver(myConflictResolver); > and my fetch is: > > bucket.fetch(id, Record.class).withResolver(myConflictResolver).execute(); > The order of operations in my test is: > > 1. Store new record > 2. Fetch the record as firstRecord > 3. Fetch the record as secondRecord > 4. Modify a field on firstRecord and secondRecord > 5. Save firstRecord > 6. Save secondRecord - this invokes my resolver with two siblings > 7. Read record - this also invokes my resolver with the two siblings > > Am I missing something? Or is this what's supposed to happen? I'm not too > worried - the double-handling is hardly that intensive - but I'm keen to > get it right. > > Thanks in advance, > Matt > > _______________________________________________ > riak-users mailing list > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- Sean Cribbs <[email protected]> Software Engineer Basho Technologies, Inc. http://basho.com/
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
