are you guys going to put a limit on the size of the updates? can
someone do an update over 50 znodes where data value is 500K, for example?
if there is a failure during the update, is it okay for just a subset of
the znodes to be updated?
ben
On 12/20/2010 06:56 PM, Qian Ye wrote:
Hi all, have we reached any consensus on this issue? What's our next step
about it?
I'm looking forward to make use of this kind of feature.
thanks~
On Fri, Dec 17, 2010 at 3:25 AM, Ted Dunning<ted.dunn...@gmail.com> wrote:
One alternative is to simply specify -1 in the version list to avoid the
version check for that one item. That would allow
the subset constraint to be retained as a valid semantic check for most
situations and would allow
a very explicit way to describe when you want to violate that constraint.
On Thu, Dec 16, 2010 at 10:06 AM, Dave Wright<wrig...@gmail.com> wrote:
I'm not sure why (other than your syntax) you would require the second
list (to update) to be a subset of the first (to test). There are
plenty of situations where you may want to update one node based on
the value of another (and test that the value hasn't changed before
updating) but don't really care about the second node, and it would
just be extra overhead to check it's current value. In fact, I think
that was the OP's situation.
-Dave
On Thu, Dec 16, 2010 at 1:01 PM, Ted Dunning<ted.dunn...@gmail.com>
wrote:
Yes. This is isomorphic to my suggestion to allow null data. We
should
toss around many options to figure out which is the most congenial
idiom.
Yours is nice since it has two sets of parallel lists.
In java with optional arguments it would be possible to use a builder
style
with optional arguments:
zk.testVersions(node1, version1, node2, version2, ...)
.updateData(node1, data1, node3, data3, ...)
I would tend to make it part of the contract that the nodes in the
second
part be a subset of of the nodes in the first part. The first method
would
create an object packaging up the first set of args and the second
method
would do the work. Of course, this is just syntactic sugar for the
more
list oriented version.
On Thu, Dec 16, 2010 at 8:16 AM, Dave Wright<wrig...@gmail.com>
wrote:
My recommendation would actually be a combination of the two which
offers the most flexibility:
zoo_multi_test_and_set(List<string> znodesToTest, List<int> versions,
List<string> znodesToSet, List<byte[]> data）
...this specifies a list of nodes& versions to check, and if the
versions match, a list of nodes to set and the associated data.
This allows multiple scenarios, including setting nodes other than the
ones you are version checking, setting more nodes than you version
check, checking more nodes than you set, etc.
I don't think the implementation would be any harder than either of
the
others.
-Dave
On Wed, Dec 15, 2010 at 10:50 AM, Ted Dunning<ted.dunn...@gmail.com>
wrote:
Well, I would just call the first method set.
And I think that the second method is no easier to implement and
probably
a
bit less useful.
The idea that the second might be almost as useful as the first is
interesting however. It probably
means that we should allow some of the data elements to be null or
something
to allow for testing
versions but not setting data.
On Tue, Dec 14, 2010 at 11:21 PM, Qian Ye<yeqian....@gmail.com>
wrote:
zoo_multi_test_and_set(List<int> versions, List<string> znodes,
List<byte[]> data）
can solve the problem I mentioned before, and some relavant issues,
like
hard for programmers to use, as mentioned in mail-archive, should
be
paid
attention to. I think we can move small step first, that is,
provide
interface like
zoo_multi_test_and_set(List<int> versions, List<string> znodes,
byte[]
data, string znode）
The API test versions of several different znodes before set one
znode,
and
if the client want to set other znode, it can call this API
repeatedly.
Because we only set one node by this API, the result will be
straight,
success or failure. We need not take care of the half-success
result.
How do ur guys think about this API?
