Ben, Can you point me to the place where the queue is inspected to convert updates into idempotent writes?
On Mon, Dec 20, 2010 at 6:56 PM, Qian Ye <yeqian....@gmail.com> 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? > > > >> >> > > > >> > > > > >> > > > > > > > > > > > > > -- > With Regards! > > Ye, Qian >
