curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Blum (JIRA)" <>
Subject [jira] [Commented] (CURATOR-151) SharedValue has limited utility but can be improved
Date Thu, 02 Oct 2014 19:49:33 GMT


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

> SharedValue has limited utility but can be improved
> ---------------------------------------------------
>                 Key: CURATOR-151
>                 URL:
>             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

This message was sent by Atlassian JIRA

View raw message