I think this has somewhat hijacked the original poster's question, but ...
doNotFetch() was never meant to be used with a Mutation or
returnBody(). It was an option added due to the aforementioned
specific feature requests.
The reason it exists is for this workflow and this workflow alone:
1) Fetch something from Riak, resolving any conflicts.
2) Do something with that data and change (mutate) the value / metadata
3) Store the changes back to Riak without specifying a Mutation or
ConflictResolver and avoiding the fetch.
It is assumed that any siblings created are dealt with in a subsequent
fetch using this workflow.
The most basic example:
IRiakObject ro = bucket.fetch("foo").execute();
ro.setValue("Some new value");
bucket.store(ro).withoutFetch().execute();
The DeafultBucket.store() in that case sets up the StoreObject to use
the PassThroughConverter and the ClobberMutation that simply returns
the passed in IRiakObject.
The Javadoc for doNotFetch() is very specific about what happens with
the Mutation:
* 1) <code>null</code> will be passed to the {@link Mutation} object (if
* you are using the default {@link ClobberMutation} this is fine).
That said, using a Mutation other than ClobberMutation with
doNotFetch() really makes little sense. The option was added for
people who have already fetched and mutated their data.
- Roach
On Sun, Aug 11, 2013 at 1:54 PM, Guido Medina <[email protected]> wrote:
> I hate it too but my point still stands, if DO NOT FETCH, what's the target
> object the mutation should work with? Isn't it the passed object instead?
>
> Anyway, I sent a pull request which hopefully applies a better semantics:
> https://github.com/basho/riak-java-client/pull/271
>
> Thanks,
>
> Guido.
>
>
> On 11/08/13 20:45, YN wrote:
>
> Guido,
>
> In this case it appears that fetching is enabled i.e. if (!doNotFetch) i.e.
> if NOT doNotFetch... so basically doNotFetch = false (fetching is true /
> enabled).
>
> I hate the double negative cases since it's easy to get confused / miss the
> logic that was intended.
> YN shared this with you.
> Re: Java client - conflict resolver on both fetch() and store()?
> Via gmane.comp.db.riak.user
>
> Brian,
>
> In StoreObject's execute() method, this condition, is it a bug or intended?
>
> ...
> ...
> if (!doNotFetch) {
> resolved = fetchObject.execute();
> vclock = fetchObject.getVClock();
> }
> ...
> ...
>
> My reasoning is: if do not fetch then shouldn't the resolved object be
> the one passed? I'm doing some tests and if I do store a mutation
> returning the body without fetching, I get a new mutated object and not
> the one I passed + mutation. So I'm wondering if that was the original
> intention.
>
> Thanks,
>
> Guido.
>
> On 11/08/13 18:49, Guido Medina wrote:
>
> _______________________________________________
> riak-users mailing list
> riak-users< at >lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
> Sent from InoReader
>
>
> _______________________________________________
> riak-users mailing list
> [email protected]
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
>
>
> _______________________________________________
> riak-users mailing list
> [email protected]
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
>
_______________________________________________
riak-users mailing list
[email protected]
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
