Create XYZ commands must return an id/name only
#20
Comments
|
I think it makes sense to just print the ids for the create operations. On the registry side the returned entities have a concept of self link, would it make sense to return that? An example would be:
Or does it make more sense to just stick with a single value?
|
bbende
added a commit
that referenced
this issue
Feb 4, 2018
…asy use in automation or copying/pasting
|
I would stick to a single value, less parsing work for responses consumer.
…On Sun, Feb 4, 2018, 1:50 PM Bryan Bende ***@***.***> wrote:
I think it makes sense to just print the ids for the create operations.
On the registry side the returned entities have a concept of self link,
would it make sense to return that? An example would be:
nifi-reg create-bucket ...
buckets/{bucketId}
nifi-reg create-flow ...
buckets/{bucketId}/flows/{flowId}
nifi-reg import-flow-version ...
buckets/{bucketId}/flows/{flowId}/versions/{versionNumber}
Or does it make more sense to just stick with a single value?
nifi-reg create-bucket ...
{bucketId}
nifi-reg create-flow ...
{flowId}
nifi-reg import-flow-version ...
{versionNumber}
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#20 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAHSR-MItCNNSwwuQiMl1vVTbL7RX0fGks5tRfvlgaJpZM4R4TgN>
.
|
|
Sounds good, the commit I pushed has the single value approach, closing this. |
bbende
added a commit
that referenced
this issue
Feb 9, 2018
- Setting up command framework - Check point for get-flow-version command - Working get-flow-version - Working commands for ListBuckets and CreateBucket - Adding more commands - Adding support for properties files and secure connections with certificates - Adding JLine to make a shell - Cleaning up JLine integration - Adding support for executing single commands, renaming to CLI - Adding command groups to organize commands based on target area - Refactoring how command options are setup - Refactoring how NiFiRegistryClient is created to make it easier to test and to support proxied entities - Implementing custom completer - Working NiFI commands for listing, adding, and updating Registry Clients - Refactoring to create an overall CLI context to pass around with a session, and adding session commands - Making use of session properties file for NiFi and NiFiReg commands - Working import-pg command for NiFi - Adding current user commands and session clear - Reorganizing packages, refactoring to separate API - Adding persistent session - Adding commands for pg-start, pg-stop, and pg-get-vars, and a basic README - Fixes #17 - Only print session info when interactive - Fixes #20 - Making all create commands return a single id value for easy use in automation or copying/pasting - Fixes #19 - Removing name from the options of pg-import since it should use the name from registry - Fixes #16 - Making flow version optional when exporting, if not specified then the latest will be exported - Fixes #18 - Removing flow version arg from import-flow-version, automatically determining next one-up version - Fixes #21 - Removing bucket id from export/import and automatically determining it
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The use case is automation/scripting. We don't need
Successfully created XYZ with ID: blahin the output.Consider either printing a single line with the ID or printing a json structure with any required additional info. Just printing an ID makes sense for the create operation (a la RESTful service), and also makes it easier to copy/paste in the interactive shell vs selecting it within verbose output.
Could add some
--jsonarg to convert every output into machine-parseable ones. Yes, very much like SVN did at the time :)The text was updated successfully, but these errors were encountered: