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? > >> >> > >> > > >> > > >
