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?
>
