> Mostly looked like this wasn¹t on our roadmap for short term, but definitely
> something to think about longer term.
Nice, thanks for the pointer. This looks precisely like the kind of
support we'd like to see implemented as well, except in our case it'd
be create/delete rather than set.
I agree with the rationale there as well: coordination gets
significantly more complex if one has to deal not only with the
problem at hand, but also with the intermediate states which have to
be put in place towards satisfying the necessary structure.
Regarding Ben's reservations, I don't share some of them:
1) Regarding blocking, the suggestion is just to group a finite number
of operations together, rather than a RDB-like begin/commit
transaction mechanism. The lack of these primitives means that the
workaround logic people have to put in place, besides being
significantly more complex to implement and understand (bugs!), also
is significantly more expensive computationally than something which
executed the operations at once (e.g. how expensive would it be to
create two nodes, vs. creating lock/liveness nodes and putting
watching in places everywhere).
2) My impression is that aborting the whole thing on any failures in
the grouped operations would be pretty easy to understand and would be
what most people would expect when using such a grouping primitive
(why would they want grouping otherwise?).
3) Regarding partitioning, my poor understanding becomes poorer.
Given all the guarantees of ordering and whatnot that ZK already has
to enforce, feels like it shouldn't be significantly harder to batch
things together, but I don't have enough understanding to say anything
here to be honest.