simonbence commented on code in PR #8726:
URL: https://github.com/apache/nifi/pull/8726#discussion_r1588954630


##########
nifi-framework-bundle/nifi-framework/nifi-framework-components/src/main/java/org/apache/nifi/registry/flow/FlowAnalyzingRegistryClientNode.java:
##########
@@ -401,13 +401,33 @@ public boolean isStorageLocationApplicable(final String 
location) {
     }
 
     @Override
-    public Set<FlowRegistryBucket> getBuckets(final 
FlowRegistryClientUserContext context) throws FlowRegistryException, 
IOException {
-        return node.getBuckets(context);
+    public boolean isBranchingSupported() {
+        return node.isBranchingSupported();
     }
 
     @Override
-    public FlowRegistryBucket getBucket(final FlowRegistryClientUserContext 
context, final String bucketId) throws FlowRegistryException, IOException {
-        return node.getBucket(context, bucketId);
+    public Set<FlowRegistryBranch> getBranches(final 
FlowRegistryClientUserContext context) throws FlowRegistryException, 
IOException {
+        return node.getBranches(context);
+    }
+
+    @Override
+    public FlowRegistryBranch getDefaultBranch(final 
FlowRegistryClientUserContext context) throws FlowRegistryException, 
IOException {
+        return node.getDefaultBranch(context);
+    }
+
+    @Override
+    public void createBranch(final FlowRegistryClientUserContext context, 
final CreateBranch createBranch) throws FlowRegistryException, IOException {

Review Comment:
   What I was thinking about is that the interface is lack of arguments with 
"verb based" or "action based" argumetnts, rather it uses data driven approach. 
This might be resolved by naming, however I am not sure about `Info` (but for 
the full truth, I have no better naming at the moment)
   
   Your reasoning about the future development of the API I can perfectly stand 
with. Still, it looks quite alien to the other signatures from the interface.
   
   Maybe the best of both worlds might be to stick with the `fromBranch` and 
`toBranch` arguments but intead of string, they might have a type `Branch` or 
alike, which might be populated with further information in the case of need. 
Just moving on with this thought experiment, if we might need further 
information about where to branch from, it can have the type of 
`BranchingPoint`.
   
   Not sure this is gonna solve everything, but I kindly ask you to consider.



-- 
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]

Reply via email to