it would be nice if it could be folded in, it does create a problem
though. the issue is that only reads do not go through the atomic
broadcast, so in some recovery cases it would be hard to get the old
data back. it's not that in can't be done, but i think it significantly
complicates the design.
it seems like the easiest way to do this would be to have the
delete-and-return operation so that the old data is explicitly put in
the recovery log. if we do delete-and-return, we probably also want
set-and-return :)
ben
On 01/15/2011 01:43 PM, Ted Dunning wrote:
I think that the multi stuff is the ideal place for this kind of capability.
To do this, we would need to add a get operation to the current collection.
I think that would be an excellent addition, not only for your use case but
also the one where you want to get consistent copies of several znodes at
once.
On Sat, Jan 15, 2011 at 8:14 AM, Scott Fines<[email protected]> wrote:
It seems like it would be a very powerful option to be able to have a
"delete-and-return" operation that atomically deletes a znode, and returns
the bytes that were previously stored in that znode. Is there a particular
reason why this was not chosen as the behavior of the API? In most of the
other generic compare-and-swap operations (put-if-absent and
set-if-matches), there is already a mechanism in place, or one can
relatively easily be implemented, but this seems like an odd oversight.
I saw that ZooKeeper-965<
https://issues.apache.org/jira/browse/ZOOKEEPER-965>
could
potentially address this in the future, but it seems like API overkill for
something like this.
