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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > 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 <[email protected]> > > >> 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 <[email protected]> > > 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? > > >> >> > > >> > > > >> > > > > > > -- With Regards! Ye, Qian
