+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 < [email protected]> 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 ([email protected]) > 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 >
