[
https://issues.apache.org/jira/browse/CURATOR-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157063#comment-14157063
]
Scott Blum commented on CURATOR-151:
------------------------------------
Thanks, much better! I did have one gut reaction on the API though. This
struck me as a little weird:
trySetCount(VersionedValue<Integer> newCount)
It's subtle so let me try to explain. Assume that you do a read and get (1,
"foo"). In order to set a new value, you need to manually construct a
versioned value (1, "bar") to attempt to do a write. If it succeeds, you end
up with a new versioned value (2, "bar"). It's actually kind of weird that a
versioned value (1, "bar") ever existed, since this isn't a real versioned
value at all, it's just a mutation attempt.
I would find it less weird if the API was:
trySetCount(VersionedValue<Integer> previous, Integer newCount)
Then, you have the nice invariant that a VersionedValue never exists unless
it's a real server state.
> SharedValue has limited utility but can be improved
> ---------------------------------------------------
>
> Key: CURATOR-151
> URL: https://issues.apache.org/jira/browse/CURATOR-151
> Project: Apache Curator
> Issue Type: Improvement
> Components: Recipes
> Affects Versions: 2.6.0
> Reporter: Jordan Zimmerman
> Assignee: Jordan Zimmerman
> Fix For: 2.7.0
>
>
> Currently, SharedValue has limited utility as the internally managed version
> is always used for trySetValue. A good improvement would be a) add an API to
> get the current value AND current version and b) add an alternate trySetValue
> that takes a new value AND an expected version.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
