PS (cont.) Or is the idea with the mutators that you have a mutator per POJO operation (add this, remove that), a corresponding conflict resolver per operation, and tailored stores accordingly? Currently I have a single persistence method for my record and a single increasingly bloated resolver which deals with all operations, so I can see how this approach isn't that scalable.
I'll stop having conversations with myself now... ;) On 11 August 2013 20:42, Matt Painter <[email protected]> wrote: > 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 > -- 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
