I think the second is easier to implement because it only updates data on one node, and need not handle rollback in the case of some update failure after some update success.
Well, I agree that the API zoo_multi_test_and_set(List<int> versions, List<string> znodes_test, List<byte[]> data, List<string> znodes_set); is more powerful. If we can decide to do this, I think we could start to discuss some implement details. On Wed, Dec 15, 2010 at 11:50 PM, 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
