NealSun96 commented on a change in pull request #759: Add validation logic to
MSD write operations
URL: https://github.com/apache/helix/pull/759#discussion_r379107200
##########
File path:
helix-rest/src/main/java/org/apache/helix/rest/metadatastore/TrieRoutingData.java
##########
@@ -89,49 +87,55 @@ public String getMetadataStoreRealm(String path)
+ DELIMITER + "\" character: " + path);
}
- TrieNode leafNode = findTrieNode(path, true);
- return leafNode.getRealmAddress();
+ TrieNode node = getLongestPrefixNodeAlongPath(path);
+ if (!node.isShardingKey()) {
+ throw new NoSuchElementException(
+ "No sharding key found within the provided path. Path: " + path);
+ }
+ return node.getRealmAddress();
+ }
+
+ public boolean isShardingKeyInsertionValid(String shardingKey) {
+ if (shardingKey.isEmpty() || !shardingKey.substring(0,
1).equals(DELIMITER)) {
+ throw new IllegalArgumentException(
+ "Provided shardingKey is empty or does not have a leading \"" +
DELIMITER
+ + "\" character: " + shardingKey);
+ }
+
+ TrieNode node = getLongestPrefixNodeAlongPath(shardingKey);
+ return !node.isShardingKey() && !node.getPath().equals(shardingKey);
}
/**
- * If findLeafAlongPath is false, then starting from the root node, find the
trie node that the
- * given path is pointing to and return it; raise NoSuchElementException if
the path does
- * not point to any node. If findLeafAlongPath is true, then starting from
the root node, find the
- * leaf node along the provided path; raise NoSuchElementException if the
path does not
- * point to any node or if there is no leaf node along the path.
+ * Given a path, find a trie node that represents the longest prefix of the
path. For example,
+ * given "/a/b/c", the method starts at "/", and attempts to reach "/a",
then attempts to reach
+ * "/a/b", then ends on "/a/b/c"; if any of the node doesn't exist, the
traversal terminates and
+ * the last existing node is returned.
+ * Note:
+ * 1. When the returned TrieNode is a sharding key, it is the only sharding
key along the
+ * provided path (the path points to this sharding key);
+ * 2. When the returned TrieNode is not a sharding key but it represents the
provided path, the
+ * provided path is a prefix(parent) to a sharding key;
+ * 3. When the returned TrieNode is not a sharding key and it does not
represent the provided
+ * path (meaning the traversal ended before the last node of the path is
reached), the provided
+ * path is not associated with any sharding key and can be added as a
sharding key without
+ * creating ambiguity cases among sharding keys.
* @param path - the path where the search is conducted
- * @param findLeafAlongPath - whether the search is for a leaf node on the
path
- * @return the node pointed by the path or a leaf node along the path
- * @throws NoSuchElementException - when the path points to nothing or when
no leaf node is
- * found
+ * @return a TrieNode that represents the longest prefix of the path
*/
- private TrieNode findTrieNode(String path, boolean findLeafAlongPath)
- throws NoSuchElementException {
+ private TrieNode getLongestPrefixNodeAlongPath(String path) {
Review comment:
Appreciate the feedback on naming - it's something that I wish to discuss.
My original naming is along the line of "findClosestNode", however I find
myself have to explain the definition of "closest". For example, given
"/a/b/c", why is "/a" the closer than "/a/x/c" (if "/a/b" doesn't exist)?
Also, saying "closest node" when `path` sometimes doesn't point to a node is
strange.
I found that "longest prefix" is the most accurate definition of what this
method is doing - it finds the longest prefix of `path` that exists in this
trie.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@helix.apache.org
For additional commands, e-mail: reviews-h...@helix.apache.org
