curator-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Blum <dragonsi...@gmail.com>
Subject Re: CURATOR-214
Date Wed, 19 Aug 2015 23:14:07 GMT
+1 just return the final node's state if you have to create parents

On Wed, Aug 19, 2015 at 7:07 PM, Jordan Zimmerman <
jordan@jordanzimmerman.com> wrote:

> It is arbitrary right now (I know Mike wants to address that). +1 from me
> on storingStatIn(). Just make sure all possible valid combinations work.
>
> -JZ
>
>
>
> On August 19, 2015 at 6:05:48 PM, Cameron McKenzie (mckenzie.cam@gmail.com)
> wrote:
>
> Guys,
> CURATOR-214 is about exposing the new API in ZK to allow returning a Stat
> when creating a new zNode.
>
> I'm looking at the fluent interface for this and was looking for some
> opinions of you guys. I was going to use the Statable interface, so the
> calls would be something like:
>
> client.create().storingStatIn(stat).forPath("/bla");
>
> Just wondering about the ordering of the storingStatIn() call. Does it make
> sense to allow storingStatIn() along with creatingParentsIfNeeded()? If so,
> presumably we just return the stat of the child node.
>
> What other ordering options should be supported? It seems fairly arbitrary
> at the moment as to what ordering is allowed for different elements.
> cheers
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message