You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Stephen Tyree (Created) (JIRA)" <ji...@apache.org> on 2012/02/22 02:36:48 UTC

[jira] [Created] (ZOOKEEPER-1396) Create zoo_append API

Create zoo_append API
---------------------

                 Key: ZOOKEEPER-1396
                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1396
             Project: ZooKeeper
          Issue Type: Improvement
          Components: c client, java client, server
            Reporter: Stephen Tyree
            Priority: Minor


I was trying to append data to a znode from the C library and I realized the workflow for that is pretty unfortunate. Essentially you need to do the following:

- call zoo_exists to get the Stat structure which contains the data length of the znode
- Allocate that many bytes plus how many you are adding to the znode dynamically in a buffer
- call zoo_get to get the data for the znode
- append the data you are append'ing to the znode in your local buffer
- call zoo_set to set the data back into the znode

If between the zoo_set and the zoo_get the data changes, sorry! You have to start from scratch. For a case where multiple consumers are trying to append data to a znode, this can become a nuisance. If there existed a zoo_append API, the workflow would become:

- call zoo_append to append the data into the znode
- If that fails, call zoo_set to create the znode with the data

Assuming zoo_append wouldn't create the znode. This would mean fewer round trips against the server and simpler code. Even the Java library, which wouldn't need to worry about calling zoo_exists, would have one fewer round trip in the typical case.

Is this a typical workflow for people? Would anyone else find this API valuable?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira