PS. I presume the advantage of the mutator approach is that it reduces the likelihood of sibling conflict resolution having to take place? Or, at least the likelihood of unresolveable conflicts? Would my the resolver and main POJO be the same using this approach?
Currently in my POJO, I'm maintaining a Map containing references to things that have changed (key being the operation, value being identifiers and data appropriate to the key) and am using this in my resolver for things which need unravelling. On 11 August 2013 14:43, Matt Painter <[email protected]> wrote: > 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 > -- 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
