Ryan0751 commented on a change in pull request #395:
URL: https://github.com/apache/curator/pull/395#discussion_r691170904
##########
File path:
curator-x-async/src/test/java/org/apache/curator/x/async/modeled/TestZPath.java
##########
@@ -57,11 +57,11 @@ public void testBasic()
assertFalse(path.startsWith(ZPath.root.child("two")));
ZPath checkIdLike = ZPath.parse("/one/{two}/three");
Review comment:
I see. That seemed like a bug to me, but I can see now when considering
the two methods the difference in contracts.
Perhaps additional documentation would be helpful here (which I'm happy to
help with).
In the parseWithId's method, I see a "TODO" comment without any explanation
of what remains to be done. Is this something we should address as well?
Do you concur that the original problem of having something like "/root" as
the first parameter should be considered valid?
##########
File path:
curator-x-async/src/test/java/org/apache/curator/x/async/modeled/TestZPath.java
##########
@@ -57,11 +57,11 @@ public void testBasic()
assertFalse(path.startsWith(ZPath.root.child("two")));
ZPath checkIdLike = ZPath.parse("/one/{two}/three");
Review comment:
Thank you for the back history.
That does make me nervous to introduce this type of change. And, given
there are other ways to construct the path the way the I want, it may not be
worth the risk.
I'd still be happy to make a few additions to the documentation (javadoc as
well as those unit test cases) so that confusion for people like me is reduced
in the future :)
Would it be more appropriate to re-purpose this PR, or create a new one?
##########
File path:
curator-x-async/src/test/java/org/apache/curator/x/async/modeled/TestZPath.java
##########
@@ -57,11 +57,11 @@ public void testBasic()
assertFalse(path.startsWith(ZPath.root.child("two")));
ZPath checkIdLike = ZPath.parse("/one/{two}/three");
Review comment:
Sorry for the churn, but now that I'm looking at this again more
closely, the current implementation does still seem to have a bug to me.
I understand that the parse() method doesn't resolve parameters, and that
parseWithID's does resolve parameters.
The unit test calls parse() on a path when parameters in it.
Example:
`ZPath checkIdLike = ZPath.parse("/one/{two}/three");`
As expected, that doesn't touch the parameters, and returns a ZPath in
checkIdLike of:
`/one/{two}/three`
Next, the "isResolved()" method is called on that path, and the unit test is
currently expecting it to be resolved:
assertTrue(checkIdLike.isResolved());
The confusion for me is: How is that considered a resolved path if
`checkIdLike` still contains the `{two}` parameter?
My change had fixed this, so that if any parameters (items in `{}`
delimiters} is found in the ZPath, it's considered unresolved.
##########
File path:
curator-x-async/src/test/java/org/apache/curator/x/async/modeled/TestZPath.java
##########
@@ -57,11 +57,11 @@ public void testBasic()
assertFalse(path.startsWith(ZPath.root.child("two")));
ZPath checkIdLike = ZPath.parse("/one/{two}/three");
Review comment:
I will update the documentation to indicate that resolved state is set
by by the appropriate parse methods and is not indicative of the presence of
parameter looking things in the path.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
