> Every functionality added to ZK will make it harder to maintain. The use case

Definitely, but it's hard to debate about features at that level.  If
we delete the whole code base, we have nothing to maintain, so given
this r.

> recursiveDelete, recursiveCreate: If you want to create /A/C/D-1 just use
> recursiveCreate and you will end up with  /A/C/D-1, even if the full parent
> path did not exist before.

You're missing the actual problem. Recursive create and delete are
non-issues per se.  They become issues once you want to use the ZK
filesystem state for coordination, which is the only advised use case
for ZK.  Other messages in this thread have already described the
problems related to intermediate state visibility, and some techniques
to deal with them.  The problem is that as the number of dynamic
pieces increase, the cost of maintaining all of that logic increases
too, and it becomes non-practical.

ZK is great at what it does, and these compound atomic operations
target real use cases for what it's most useful at.  In my view, the
additional complexity in the code would not be so great to have this
feature, and it would be absolutely nothing if compared to the
additional logic which these realistic use cases require to deal with
intermediate states.

Gustavo Niemeyer

Reply via email to