justinmclean commented on code in PR #5293: URL: https://github.com/apache/gravitino/pull/5293#discussion_r1849330748
########## docs/cli.md: ########## @@ -506,6 +507,26 @@ gcli tag update --tag tagA --rename newTag gcli tag update --tag tagA --comment "new comment" ``` +### Owners commands + +#### List an owner + +```bash +gcli catalog details --name postgres --owner +``` + +#### Set an owner to a user + +```bash +gcli catalog set --name postgres --user admin Review Comment: Thanks for pointing out that bug, I'll get that fixed. Re code effort if we set the owner via a command, we need <no of entities> blocks of code, if we set it via a flag, it's one block of code, but let us ignore that for a moment. Fewer commands benefit users, as people can only remember a limited number of things. Introducing additional commands may make it harder for users to keep track, and even confusing if they are similarly named, even if individual commands are relatively easy to recall. It has other benefits as well, reducing cognitive load and the learning curve, giving consistency and predictable patterns leading to a better user experience. Flags are easier to remember as you only have a small set of flags that are used with any given command. However overloading flags can make it harder for a user to understand or predict a CLIs behavior, and flags can be less discoverable or hard to match with the command they apply to without documentation. In general new commands are used for entirely distinct operations and flags are used modify or refine the behavior of existing commands. There are downsides to both approaches here, and I don't think there is an ideal solution. So we need to pick one, and I think on balance using a flag makes it clearer for the user given that the operations are all similar. -- 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]
