-
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): improve CLI transient queries with headers and spacing (partial fix for #892) #3047
Conversation
May I suggest a slight cosmetic adjustment to match MySQL?
Mostly curious to see how it looks if we try to line 'em up |
This is great @agavra , I agree with @MichaelDrogalis 's comment on matching MySQL. Postgres also is very similar to MySQL. That way it would really look and feel like a database! ;) |
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
Some suggestions below. The reason I've requested changes is the attempt to get a fix in for the double meta column bug, which is fixed in my own PR.
private final List<String> value; | ||
private final List<String> header; | ||
|
||
public TabularRow( |
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.
header
and value
are used mutually exclusively. They both map to a list of strings. So this class could be simplified to just take the width and single List<String>
param, pushing up the computation of what is passed as the list of strings to the caller, or maybe two factory methods.
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.
the reason I have it this way is that in the near future I want to change the column format based on the header - so passing in both will soon be helpful (e.g. fixed width for int columns, etc...)
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.
OK, in that case I'd still go for two factory methods to make this clear:
TabularRow.createHeader(headers)
vs TabularRow.createRow(headers, row)
.
And you can still decouple this class from FieldInfo
and GenericRow
by having the calling code do the toString
stuff. Less couple is good! Plus, you can process the headers once for the query, rather than per-row.
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.
And you can still decouple this class from FieldInfo and GenericRow by having the calling code do the toString stuff.
I don't think the current calling class would be a good place to do that. I could introduce another wrapper class (e.g. Tabular
) that handled all of the row widths based on the field infos and things like that, but that is overkill for this PR. As it stands, it's pretty decoupled - it's just in a constructor (moved to be static initializer).
@@ -39,7 +39,17 @@ public KsqlBareOutputNode( | |||
final OptionalInt limit, | |||
final TimestampExtractionPolicy extractionPolicy | |||
) { | |||
super(id, source, schema, limit, extractionPolicy); | |||
super( |
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.
Don't think adding this was intentional.... we shouldn't be doing this.
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.
I was just hacking it to make it work - wasn't going to commit until your fix is in :)
ksql-rest-app/src/main/java/io/confluent/ksql/rest/util/EntityUtil.java
Outdated
Show resolved
Hide resolved
ksql-common/src/main/java/io/confluent/ksql/schema/ksql/LogicalSchema.java
Outdated
Show resolved
Hide resolved
} | ||
|
||
@Test | ||
public void shouldMultilineFormatRow() { |
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.
Add test for what happens if the number of columns is higher than the width....
Interesting edge case!
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! I think if this is the case I'll default back to the old behavior
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.
I've decided to set a minimum cell width of 5 - it'll look all weird if the terminal is super small, but that's going to be the case anyway
@agavra While testing this, I see that the output fits the full screen. Can we use a fixed column instead? Mysql and other Dbs do not fit the whole screen, although I understand that those DBs know what's the max value read to use it in the column width, and KSQL does not know as it is streaming real-time data. Btw, if I stop the query and rerun it again, the headers are not displayed anymore.
|
@spena - I'm not sure what's going on with your terminal, but my headers do show multiple times... and yeah, my concern was that I don't know the max value length when I start it up. The other SQL engines also have more powerful formatting options for the user to choose how they want it to show up. I think until we implement those, we should have a good default option (which, to me, full width makes sense)
Also tested with resizing terminal:
|
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.
LGTM! Thanks @agavra -- very nice feature :)
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 for the update @agavra.
I'm with you on using the full width by default as a good starting point.
private final List<String> value; | ||
private final List<String> header; | ||
|
||
public TabularRow( |
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.
OK, in that case I'd still go for two factory methods to make this clear:
TabularRow.createHeader(headers)
vs TabularRow.createRow(headers, row)
.
And you can still decouple this class from FieldInfo
and GenericRow
by having the calling code do the toString
stuff. Less couple is good! Plus, you can process the headers once for the query, rather than per-row.
} | ||
|
||
@SuppressWarnings("ForLoopReplaceableByForEach") // clearer to read this way | ||
private static void toString( |
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.
nit: rename formatRow
or something.
Description
Ladies and Gentlemen, the moment you have all been waiting for! Hot off the press 🔥 🔥 🔥 Formatted CLI output for transient queries, with a shiny new header row 🎉 🎉 🎉
It even does very fancy 💃 🕺 wrapping for lines that are too long and adjusts based on your terminal size.
Notes
This has a hacked version of #3043 as part of it, we should resolve that independently
Testing done
Reviewer checklist