[
https://issues.apache.org/jira/browse/CURATOR-608?focusedWorklogId=639343&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-639343
]
ASF GitHub Bot logged work on CURATOR-608:
------------------------------------------
Author: ASF GitHub Bot
Created on: 18/Aug/21 16:45
Start Date: 18/Aug/21 16:45
Worklog Time Spent: 10m
Work Description: Randgalt commented on a change in pull request #395:
URL: https://github.com/apache/curator/pull/395#discussion_r691149748
##########
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:
The contract for `ZPath.parse()` is that it does _not_ recognize
parameters. This is why the original test is `assertFalse`. This PR changes
this contract. `parseWithIds()` should be used instead.
##########
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:
> Perhaps additional documentation would be helpful here (which I'm
happy to help with).
We'd really appreciate that!
> n the parseWithId's method, I see a "TODO"
Man - I don't remember :( the code looks good to me now though
> Do you concur that the original problem of having something like "/root"
as the first parameter should be considered valid?
I'm not sure. Curator (and ZooKeeper itself) has historically had a lot of
trouble with leading slashes and the root path (`/`). I'd like to see copious
testing on this if we were to make a change. For example, over the years we've
gotten PRs trying to change how `ZKPaths.java` works and they all introduce
problems. I'm not saying the way it's implemented is ideal but that it may be
too late on this.
##########
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:
Up to you - whatever is easiest
##########
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:
`ZPath.parse()` doesn't consider IDs. The use-case here people who put
things in their path that look like ZPath IDs. They don't want them considered
as IDs and want them treated as normal paths. So, yes, it's correct in this
test that isResolved() returns true.
--
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]
Issue Time Tracking
-------------------
Worklog Id: (was: 639343)
Time Spent: 2h 20m (was: 2h 10m)
> ZPath resolved state documentation improvements
> -----------------------------------------------
>
> Key: CURATOR-608
> URL: https://issues.apache.org/jira/browse/CURATOR-608
> Project: Apache Curator
> Issue Type: Bug
> Components: Framework
> Affects Versions: 5.1.0
> Reporter: Ryan Ruel
> Priority: Major
> Fix For: 5.2.1
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> ZPaths support parameters, which are special path elements in parenthesis
> (i.e., \{one}) that may be substituted with values at runtime.
> ZPaths also have a resolved state, which checks if a ZPath parsed with
> `parseWithIds()` still contains any parameters left to be substituted.
> Additionally, ZPaths may be created with `parse()` which contain string
> elements which appear to be parameters (elements in parenthesis) but are not
> treated as such, always resulting in a path which is considered
> fully-resolved.
> The documentation for these methods should be updated to better indicate this
> behavior difference, clearly stating what "resolved" state indicates based on
> the method that generated the ZPath.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
