Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Zookeeper, mail # user - Re: need for more conditional write support


+
Dave Wright 2010-12-16, 16:16
+
Ted Dunning 2010-12-16, 18:01
+
Dave Wright 2010-12-16, 18:06
Copy link to this message
-
Re: need for more conditional write support
Jared Cantwell 2010-12-16, 18:39
I think that syntactic sugar can be very limiting.  What if you have X
children you would like to update, but don't know X until runtime?  I like
the idea of lists that don't have to be subsets of each other, giving more
flexibility.  I also think it would be interesting to discuss what
additional recipes could be developed with this api.

~Jared

On Thu, Dec 16, 2010 at 1:06 PM, 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.
+
Henry Robinson 2010-12-16, 19:04
+
Ted Dunning 2010-12-16, 19:21
+
Ted Dunning 2010-12-16, 19:22
+
Ted Dunning 2010-12-16, 19:23
+
Ted Dunning 2010-12-16, 19:25
+
Qian Ye 2010-12-21, 02:56
+
Ted Dunning 2010-12-21, 03:22
+
Benjamin Reed 2010-12-21, 05:24
+
Benjamin Reed 2010-12-21, 05:24
+
Ted Dunning 2010-12-21, 06:08
+
Benjamin Reed 2010-12-21, 06:57
+
Jared Cantwell 2010-12-21, 21:16
+
Henry Robinson 2010-12-21, 21:30
+
Ted Dunning 2010-12-21, 21:48
+
Jared Cantwell 2010-12-22, 01:44
+
Ted Dunning 2010-12-22, 02:06
+
Henry Robinson 2010-12-22, 09:00
+
Ted Dunning 2010-12-22, 18:29