Thanks Sean. I understand that the fetch-modify-write is the approach that I'm *not* taking in this case, as I am using withoutFetch() and setting a @RiakVClock in my POJO.
I just need to weigh up whether the ideal way is sufficiently better to rejig bits of my code - but I think that's a different issue :) M On 11 August 2013 14:32, Sean Cribbs <[email protected]> wrote: > 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/ > -- Matt Painter [email protected] +64 21 115 9378
_______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
