zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: need for more conditional write support
Date Thu, 16 Dec 2010 19:25:03 GMT
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 <wrightd@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.dunning@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 <wrightd@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.dunning@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.zju@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?
> >> >>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message