Being lazy, I would suggest only the tests we already have. Existence and
version.
On Sat, Aug 17, 2019, 5:30 AM Enrico Olivelli <eolive...@gmail.com> wrote:
> Il sab 17 ago 2019, 08:01 Ted Dunning <ted.dunn...@gmail.com> ha scritto:
>
> > It definitely sounds like a nice feature.
> >
> > The important question is what is the actual importance after you
> multiply
> > it by the amount of usage it gets.
> >
> > For instance, I know that multi gets a bit of usage, but I would guess
> that
> > it actually gets very, very little. It might even most of the cases that
> > you have in mind.
> >
> > If that is so, how much would an extension to multi actually be used?
> >
>
> I am adding a question: how will the 'test' look like? I image these cases:
> - test if node exists
> - test about version
> - test about the content of the znode? (This will be trickers, are zk does
> know nothing about the format of the content)
>
>
> Enrico
>
>
>
> >
> >
> > On Fri, Aug 16, 2019 at 8:28 PM Michael Han <h...@apache.org> wrote:
> >
> > > This sounds a nice feature to me as it enables user to do more without
> > > obvious downside. It could be useful in cases like state management
> where
> > > the state is stored in a fine grained approach across multiple zNode,
> > > instead of in a single zNode.
> > >
> > > On Fri, Aug 16, 2019 at 11:52 AM Ted Dunning <ted.dunn...@gmail.com>
> > > wrote:
> > >
> > > > The recent discussion about if/then/else idioms in ZK has raised the
> > > > thought that it might be nice to have some extended semantics.
> > > >
> > > > One version that I could see would be to to extend the current
> multi-op
> > > to
> > > > allow multiple alternatives. The idea would be that there would
> > > effectively
> > > > be multiple branches to be tried. The first one that succeeds
> > atomically
> > > > (all or nothing) would be used. The returned value would need to
> > somehow
> > > > indicate which alternative succeeded and would need to return any
> data
> > > > accessed. The testing of alternatives would also be atomic so it
> > wouldn't
> > > > be possible for things to change within a single operation.
> > > >
> > > > This extension would allow the previous question to be answered like
> > > this:
> > > >
> > > > pick_first {
> > > > create(...)
> > > > } {
> > > > set(...)
> > > > }
> > > >
> > > > (the syntax here is just made up and wouldn't actually be supported
> ...
> > > it
> > > > is just for pseudo code purposes).
> > > >
> > > >
> > > > My theory is that this would be relatively easy to implement based on
> > the
> > > > current multi operation. Risk due to the change is pretty low given
> > that
> > > > there is code to copy.
> > > >
> > > > My question is whether this would actually have all that much
> benefit.
> > > >
> > > > Does anybody have an opinion on that?
> > > >
> > >
> >
>
