I think this is the interface Ted eluded to, but I wanted to throw it out
there more concretely:
zoo_multi_test_and_set(List<string> znodesToTest, List<int>
versions, List<string> znodesToModify, List<OperationType>
typeOfModifications, List<byte[]> data）
You can still keep it a subset by requiring that creations explicitly set
the test version to -1. This type of interface would really open up the
capability of multi_test_and_set(). I have no idea how much more
complicated it would be to implement, but I can imagine each operation type
having Test() and Commit() operations. I think that by limiting it to only
updates from the start we may do work that will need reversed to make this
extension on the interface functional.
~Jared
On Tue, Dec 21, 2010 at 4:48 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:
> On Tue, Dec 21, 2010 at 1:30 PM, Henry Robinson <he...@cloudera.com>
> wrote:
>
> > This is a more complicated requirement, and not something that can be
> done
> > right now with Zookeeper even in a single operation on a single znode.
> The
> > only conditional operations are updates.
>
>
> Actually, creates and deletes are conditional also. Creates are
> conditional
> on the file
> not existing previously and deletes can accept a version number.
>
>
> > Designing an API to support three
> > different kinds of operation would also be more complicated, and the
> > implementation would be trickier.
> >
>
> This is definitely true. Conceptually it is the same thing, but
> practically
> building a usable API is
> a bit tricky. Using a builder style would work, though. For example:
>
> Zookeeper zk = ...;
>
>
> zk.transaction()
> .create("/foobar")
> .update("/pig", data, version)
> .delete("/dog"", otherVersion)
> .commit()
>
> Another option would be to pass a list of operations which can be one of
> Create, Update or delete.
>
