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_r379142990
########## 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: Thank you for the feedback. If you know the logic but still find it confusing, then that definitely is an indication. I coded this so I can't possibly have an objective view on it. While I agree that the current naming isn't the best, I'm not very keen about "closest node" either. Let me keep the discussion open so that there may be some second opinions coming in. I'll make sure to update the name before the PR is checked in. Thanks! ---------------------------------------------------------------- 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