In particular, you can do something like this
contents, version = get(x/y/z)
multi([delete(x/y/z, version), create(a/b/c, contents)])
The multi will fail if x/y/z has been updated between the get and the
multi. The multi will also fail
if a/b/c cannot be created. If the multi succeeds, x/y/z will not exist
and a/b/c will have the former
content. If the multi fails, nothing will change. You would want to
repeat this until it succeeds.
This is ugly only in that you have to repeat it until it succeeds and in
that the data has to make
a round trip to the client and back. The second should be less of an issue
if you remember that
Zookeeper is a coordination service rather than a data storage system.
On Thu, Nov 15, 2012 at 12:02 PM, Camille Fournier <[EMAIL PROTECTED]>wrote:
> You can simulate this using multi transactions in the current system. I
> think the transactionality of move in the way you are suggesting breaks
> down to a multi transaction, so implementing it as a special api call may
> be considered redundant.
> On Thu, Nov 15, 2012 at 2:14 PM, Robin Bate Boerop <
> [EMAIL PROTECTED]> wrote:
> > Zookeeper users,
> > Has anyone investigated the implementation of a 'move' operation in
> > Zookeeper?
> > For example, suppose that a node '/x/y/z' has 50 Ko of data associated
> > with it. A client wants the same data to be found only in node '/a/b/c'.
> > The client must:
> > 1. Get the contents of '/x/y/z', incurring a transfer of the 50 Ko of
> > from ZK.
> > 2. Create node '/a/b/c' with the same 50 Ko of data, incurring another
> > transfer of it.
> > 3. Delete node '/x/y/z'.
> > It would be simpler to issue a 'move' command: move('/x/y/z', '/a/b/c').
> > This would also be much faster.
> > --
> > Robin Bate Boerop