Console output should adjust based on console size

[ndimiduk]

Current behavior is to truncate column output when the console is not wide enough. The output table makes no indication that additional columns are present. Output should be produced in a more ergonomic manner. See another user's report of the same over on DRILL-3129.

[ndimiduk]

All the products I've seen wrap the output. It's arguably less readable, but at least you can find the data you're looking for/know it's there.

[JamesRTaylor]

Drill has done some nice enhancements to sqlline wrt the width of the column being smaller if the content is smaller. It'd be nice if that made it back here.

[julianhyde]

1. If you want the console to wrap the output, you are basically asking to set maxwidth to infinity. We could support that via

!set maxwidth -1

Drill would need to pass that in when it starts up. If it doesn't pass it in, sqlline will deduce maxwidth from the terminal.

1. There is also maxcolumnwidth but it doesn't seem to be working. If it worked you could do

!set maxcolumnwidth 20

and the output from !tables would be more readable.

1. Sqlline can deduce the actual width of columns. When it does this, output of result sets with a lot of string columns of unbounded length (such as !tables) becomes a lot more readable. You just need to call

!set incremental false

And in fact, maybe incremental should be false by default.

1. Lastly, as a workaround, I hope you know that there are other output options. I find

!set outputformat csv

useful if there are a lot of string columns.

[JamesRTaylor]

Thanks, @julianhyde - didn't know about the {{!set incremental false}} option. We'll give that a try in Phoenix.

[ndimiduk]

There's a lot of good info in all the Julian; thanks! Maybe we can move toward a more dynamic set of defaults? My Phoenix users are having a bad experience consuming these fixed width output. They're much more accustomed to the awful wrapping psql does and we have an opportunity to give an improved experience overall.

On Thursday, January 7, 2016, James Taylor [email protected] wrote:

Thanks, @julianhyde https://github.com/julianhyde - didn't know about the {{!set incremental false}} option. We'll give that a try in Phoenix.

— Reply to this email directly or view it on GitHub https://github.com/julianhyde/sqlline/issues/36#issuecomment-169855479.

[JamesRTaylor]

Do your users use SQuirrel? I think that's a better user experience. The other SQL client we should look at is Apache Zeppelin.

On Friday, January 8, 2016, Nick Dimiduk [email protected] wrote:

There's a lot of good info in all the Julian; thanks! Maybe we can move toward a more dynamic set of defaults? My Phoenix users are having a bad experience consuming these fixed width output. They're much more accustomed to the awful wrapping psql does and we have an opportunity to give an improved experience overall.

On Thursday, January 7, 2016, James Taylor <[email protected] javascript:_e(%7B%7D,'cvml','[email protected]');> wrote:

Thanks, @julianhyde https://github.com/julianhyde - didn't know about the {{!set incremental false}} option. We'll give that a try in Phoenix.

— Reply to this email directly or view it on GitHub <https://github.com/julianhyde/sqlline/issues/36#issuecomment-169855479 .

— Reply to this email directly or view it on GitHub https://github.com/julianhyde/sqlline/issues/36#issuecomment-170182104.

[ndimiduk]

No, they're not on the same network as the cluster. Right now it's sqlline through a gateway host and/or Jupyter Notebooks on the same.

[julianhyde]

@ndimiduk, I presume you are calling sqlline via a wrapper script. Before we go changing defaults, you can specify the values you'd like for your users in the wrapper script. If we eventually reach consensus that those values are better than the defaults, then we can change the defaults.

Maybe you no longer need it, but I do also like the idea of changing the formatting of the table output format to give some kind of cue that lines have been truncated.

[ndimiduk]

Let me experiment with the options available and report back.

+1 on cue to indicate truncation.

On Saturday, January 9, 2016, Julian Hyde [email protected] wrote:

@ndimiduk https://github.com/ndimiduk, I presume you are calling sqlline via a wrapper script. Before we go changing defaults, you can specify the values you'd like for your users in the wrapper script. If we eventually reach consensus that those values are better than the defaults, then we can change the defaults.

Maybe you no longer need it, but I do also like the idea of changing the formatting of the table output format to give some kind of cue that lines have been truncated.

— Reply to this email directly or view it on GitHub https://github.com/julianhyde/sqlline/issues/36#issuecomment-170291274.

[ndimiduk]

Just to report back, !set incremental false helps a lot with things like listing tables schema.

[JamesRTaylor]

Agreed - we just made that the default for Phoenix 4.7.0.

[benjdv]

With !set outputformat table

Why not to put a marker on truncated column to avoid confusion. For example, pgadmin used "(...)" to indicate that the string have been truncated for display

But there is an other problem with this mode : the too long column is truncated and above all, next columns are not display at all without any report/alarm/sign.

And finally it's difficult to control the printed character, because the number depends on size of other columns and even worse on size of other columns on other rows.

So, It will probably be useful to have :

• an option to define the max length of one column
• a marker to distinguish truncated column.