Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (athena.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.213.170 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=xHs2rBPzQ31/WoCTg/ZtuFfziPCgObCx7FCMO7by6MTMZVlcKgrx7JfYQKtfHWDrxf
         cpxsd0QqnvHBRyd0eQEUxKF9fiqSCGPuYFiQvY2KMGgXB2Wd5RzDD2bOYeS3Uj9hlrFE
         ft6lDkzSqxEjfnCF+ZN9xv478ufN/ec80+k2M=
MIME-Version: 1.0
In-Reply-To: <AANLkTintPOsE_ANJo8UKKOfnLg7widDxzu9G9CbjVzB+@mail.gmail.com>
References: <AANLkTinAbuopWyDathERkdoJ-jK-QbNFVy-0SgrPbqh9@mail.gmail.com>
 <AANLkTinWVHequQ6-6Jzj=GbT0f-M+UgyXC5=6F_TM6re@mail.gmail.com>
 <AANLkTinSW97+rF5gxWt+v407tAO7c92zEWBjzRjhabw9@mail.gmail.com>
 <AANLkTinu7wmo6TT5gLWAx4KF4Q-jWYdFfeRGkEpitTYN@mail.gmail.com>
 <AANLkTi=HOLaVQLp-YC5D-bvwHhzHLyJRxs8zPbjRiS+u@mail.gmail.com>
 <AANLkTi=H5UqrwBK6MAuib5kVgFis9SkfnoMFX3VL4hvA@mail.gmail.com>
 <AANLkTikPFz+dCUc0M4NA+fOBtAk6Y8EvCwmJ=YgBDUrn@mail.gmail.com>
 <AANLkTimWB+qcfQY9cJPKhmkbVCxR++xRSUNPCaaK+Jvw@mail.gmail.com>
 <AANLkTintPOsE_ANJo8UKKOfnLg7widDxzu9G9CbjVzB+@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Thu, 16 Dec 2010 11:25:03 -0800
Message-ID: <AANLkTi=bSqAw8j++DFEF=BMHk4FEy9NMuYJmNUfj1KNw@mail.gmail.com>
Subject: Re: need for more conditional write support
To: user@zookeeper.apache.org
Content-Type: multipart/alternative; boundary=0023547c9015e9eb8d04978c0364

--0023547c9015e9eb8d04978c0364
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 shoul=
d
> > toss around many options to figure out which is the most congenial idio=
m.
> >  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 seco=
nd
> > 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 meth=
od
> > would do the work.  Of course, this is just syntactic sugar for the mor=
e
> > 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=EF=BC=89
> >>
> >> ...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 th=
e
> >> 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=EF=BC=89
> >> >>
> >> >> can solve the problem I mentioned before, and some relavant issues,
> like
> >> >> hard for programmers to use, as mentioned in mail-archive, should b=
e
> >> paid
> >> >> attention to. I think we can move small step first, that is, provid=
e
> >> >> interface like
> >> >>
> >> >> zoo_multi_test_and_set(List<int> versions, List<string> znodes,
> byte[]
> >> >> data, string znode=EF=BC=89
> >> >>
> >> >>
> >> >> 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 resul=
t.
> >> >>
> >> >> How do ur guys think about this API?
> >> >>
> >> >
> >>
> >
>

--0023547c9015e9eb8d04978c0364--