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()?
<http://permalink.gmane.org/gmane.comp.db.riak.user/12099>
Via gmane.comp.db.riak.user
<http://blog.gmane.org/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 <http://www.inoreader.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
