-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cli): add the feature to turn of WRAP for CLI output #3341
Conversation
My gut says this is confusing. Maybe we can have another command such as |
Yeah, I think this is going to be confusing:
Do we need to introduce a
Or inverted and probably easier to add on top of what we've got:
|
Thinking into the future... we are likely at some point to allow people to set their own date and time formats. This is pretty common functionality.
What's interesting here is that this would likely be both a client setting, as we'd use it in the CLI to format dates, and also potentially a server setting, i.e. it's passed to the server to allow it to parse supplied date. So... do we really want to differentiate? Also, why should the user care if the property is affecting the client or the server? Take WRAP - should the user care if its the server doing the wrapping before sending the output to the client, of the client doing it locally? Just throwing that out there for thought! ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @agavra
LGTM, 'cept I'm left wondering what was gained by moving the maybeHandleCliSpecificCommands
call into the CLI
aside from more code and having to take the line the console returned and immediately ask that same console if this is actually an internal command it should handle... I don't get it.
Plus see comment above about syntax.
ksql-cli/src/main/java/io/confluent/ksql/cli/console/cmd/SetCliProperty.java
Outdated
Show resolved
Hide resolved
ksql-cli/src/main/java/io/confluent/ksql/cli/console/cmd/SetCliProperty.java
Outdated
Show resolved
Hide resolved
ksql-cli/src/main/java/io/confluent/ksql/cli/console/cmd/SetCliProperty.java
Outdated
Show resolved
Hide resolved
Thanks for the review @big-andy-coates!
Every single time I've looked at this code, I have to dig through and find where we handle the CLI specific commands. I think it makes a lot of sense to have the code be:
instead of
IMO, whether a command is CLI-specific or not should be part of "handling" not "reading". |
@big-andy-coates - with regards to syntax, I suppose it doesn't matter except that otherwise I need to dig into the contents of the command to figure out whether it's a CLI property or not. That seems... undesirable. |
IMHO the change makes the code worse, not better. As I see it you've changed: Cli -> get next line to execute from Console To Cli -> get next line to execute from Console IMHO this is breaking encapsulation. Previously only the Console knew about the internal commands. It dealt with them. Now the Cli needs to know about them too, but only in so much as to ask the console to handle any of the lines the console just returned. To put it another way - previously the Console returned any lines it couldn't handle to the Cli. Now the Console returns all lines, only for the Cli to have to immediately pass them back to the Console to see if it can handle them. What's the point? Maybe if you were to revert this change and then rename I totally agree the architecture of the CLI is questionable. But I don't think this change helps. It actually couples code more, rather than less. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @agavra
I'm still not liking the move of the Cli specific command handling as I noted above.
Also, just a thought... but in terms of the functionality this PR provides I'm not sure WRAP
is the right name. Maybe this is a standard thing, but for me I would not expect any clipping of output to be controlled by WRAP
. I would of expected WRAP
ON
to cause long lines to be wrapped over multiple lines and WRAP
OFF
to mean long lines mean wide columns.
The functionalty feels to me like it would be better called CLIPPING
. OFF
means long output and ON
means truncated/clipped.
Don't know if the WRAP
was inspired by other similar features on other DBs, but I think its a poor name.
@big-andy-coates - okay, I will change the readline method back. This syntax was inspired by Oracles SqlPlus: https://docs.oracle.com/cd/B19306_01/server.102/b14357/ch12040.htm where they use
|
Fair enough, I wondered if that was the case. Though... I thought you always looked to Postgres for inspiration - what's with following SqlPlus?!?!? :p |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @agavra LGTM 'cept for a possible put in the clipping
&& parts.subList(rowsToPrint, parts.size()) | ||
.stream() | ||
.map(String::trim) | ||
.noneMatch(String::isEmpty); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// clip if there are more than one line and any of the remaining lines are non-empty
Isn't this check "if there are more than one line and NO LINES ARE EMPTY". So it would return false
if there are multiple lines and one is empty.
I think maybe you want '! parts....allMatch(String::isEmpty)'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good catch! added a test for it
fixes #3336
Description
SET CLI PROPERTY VALUE
syntax (which is different fromSET property=value
KSQL syntax)... perhaps this is confusing so I'm open to suggestionsSET CLI WRAP ON/OFF
toggles line wrapping (see example below)The help message:
TODO
CliConfig
, but I'm not sure how to get that workingTesting done
Reviewer checklist