[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975702#action_12975702
]
Henry Robinson commented on ZOOKEEPER-965:
------------------------------------------
Hi Ted -
I took a quick look at the github branch. Looks really good, thanks.
I've got a few comments on the code itself, but I'll save those until you post
a patch. My main issue is the following: the 'multi' API call is expressed in
terms of an iterable over a polymorphic type, both of which are Java features
that aren't extant in C. To aid future language bindings authors and to make
the implementation really easy to verify, I'd like to see an API signature
that's very easily translated between languages. The iterable isn't too
concerning (almost every language has *some* notion of lists) but the
polymorphic op object should map onto some simpler struct type.
I know that the serialisation is independent of the signature, so we could call
it whatever we liked in any language, but I'd like to keep the core ZK API
consistent across all bindings where possible and use wrappers in, for example,
Python to provide more idiomatic interfaces. The serialisation may also change
when we finally vote jute off the island, so we can't use that as the API spec.
Indeed, we'll probably use Avro, where we have to write APIs in
language-agnostic IDLs.
So, to cut a long story short: any chance you can make the API a bit more
language neutral? Then the op stuff can be a (very) thin wrapper. Shouldn't be
a large change at all.
You might consider chopping this up into a few JIRAs (apologies if you have and
I've missed them) - core API, Java wrapper, finishing touches (like payload
size limits).
Excited to see this! Let me know how I can help.
Henry
> Need a multi-update command to allow multiple znodes to be updated safely
> -------------------------------------------------------------------------
>
> Key: ZOOKEEPER-965
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965
> Project: ZooKeeper
> Issue Type: Bug
> Reporter: Ted Dunning
> Fix For: 3.4.0
>
>
> The basic idea is to have a single method called "multi" that will accept a
> list of create, delete, update or check objects each of which has a desired
> version or file state in the case of create. If all of the version and
> existence constraints can be satisfied, then all updates will be done
> atomically.
> Two API styles have been suggested. One has a list as above and the other
> style has a "Transaction" that allows builder-like methods to build a set of
> updates and a commit method to finalize the transaction. This can trivially
> be reduced to the first kind of API so the list based API style should be
> considered the primitive and the builder style should be implemented as
> syntactic sugar.
> The total size of all the data in all updates and creates in a single
> transaction should be limited to 1MB.
> Implementation-wise this capability can be done using standard ZK internals.
> The changes include:
> - update to ZK clients to all the new call
> - additional wire level request
> - on the server, in the code that converts transactions to idempotent form,
> the code should be slightly extended to convert a list of operations to
> idempotent form.
> - on the client, a down-rev server that rejects the multi-update should be
> detected gracefully and an informative exception should be thrown.
> To facilitate shared development, I have established a github repository at
> https://github.com/tdunning/zookeeper and am happy to extend committer
> status to anyone who agrees to donate their code back to Apache. The final
> patch will be attached to this bug as normal.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
