[
https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975451#action_12975451
]
Thomas Koch commented on ZOOKEEPER-965:
---------------------------------------
Continuing a short conversation from
https://github.com/tdunning/zookeeper/commit/1b1cbff2e38bc04b53174381b485304c87d5f743
here.
We could introduce operation classes for all operations, including getChildren,
getData and exists with ZOOKEEPER-911 and use these operation classes instead
of the Op classes introduced by Ted. The MultiTransaction class would of course
only accept write operations (Create, setData, Delete). This could be enforced
either manually or with an interface "WriteOperation".
Having an interface "Operation" doesn't mean you couldn't have an abstract
"BaseOperation" which could implement interface and be a base for the other
operations to extend. I also don't like to have interfaces for everything. But
making Operation an interface could make testing a lot easier.
Regarding the naming Op vs. Operation: We have more then 640k of memory
nowadays and screens show more then 80 characters in a line. So we gained the
possibility to write readable code. If you talk about it, would you say "Op" or
"Operation"? So to avoid confusion it makes sense to write the class the same
as you'd call it when speaking. Even with modern IDEs there may be cases when
one wants to search for names. "Op" could also be in "Option", "Operator",
"Open", .
If you don't mind, I really loved reading "Clean Code" from Robert C. Martin.
He also explains naming guidelines and it's a nice book to read.
> 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.
