[ 
https://issues.apache.org/jira/browse/HADOOP-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528162
 ] 

stack commented on HADOOP-1789:
-------------------------------

I think a single line only of a column, row, or cell content insufficient.  Its 
not hard to imagine rows of length > than the column widths of 20 or 30 
characters.  Same for column.  I think that if the row or column is truncated 
in a long listing of table content, the listing will be of little use.  The 
user will not be able to discern explicit row/column addresses.

I spent some time looking at Izaaks patch and playing more with Freemarker 
trying to have it format a 'row' rather than a emit a line-per-row as is done 
in Izaaks' patch.  In Freemaker there is no while loop construct and passing 
template data structures back into custom java methods only seems to work for 
simple, non-list types (making it hard to pass back into the custom code the 
row columns passed the template and any properites that may have been set in 
the template).  It might be possible to make it work eventually but the 
resulting template, I feel,  would be an unintelligible markup mess.  I'm now 
of the mind that Freemarker/Velocity is not up to the task and it would just be 
faster writing the formatting in java.  We can supply multiple ConsoleTable 
instances; one per output type that we want to support with a particular one 
chosen by params passed the shell on startup.

> [hbaseshell] output formatting
> ------------------------------
>
>                 Key: HADOOP-1789
>                 URL: https://issues.apache.org/jira/browse/HADOOP-1789
>             Project: Hadoop
>          Issue Type: New Feature
>          Components: contrib/hbase
>            Reporter: stack
>            Priority: Minor
>         Attachments: console_templates.patch
>
>
> hbaseshell currently outputs results using an ascii table.
> This issue is about the hbaseshell offering a number of output formats beyond 
> plain ascii table.  It would be grand if output formatting was pluggable so 
> folks could add new ones as they saw fit.
> Currently, there is a painful need for unadorned output so folks can do a 
> 'select page:content from webrepository where 
> row="http://apache.com/index.html";; and they get back the page content only.  
> Other output formats might be: csv, xml, or (x)html
> Other related things to consider, but probably not as part of this issue, is 
> that if we output xml, then we should probably have a sympathetic input 
> parser for xml files (similar for csv).  Let this issue just be about 
> formatting (another issue can be done to add pluggable input parsers).  Where 
> the output lands should also be done in another issue: i.e. dependent on the 
> command, output probably default to stdout but folks should be able to 
> designate an output file (and target filesystem) as in 
> hdfs://master.hdfsnode.com:8990/output/dump.txt or file:///tmp/dump.txt or 
> s3://...., etc.
> This issue is an outgrowth of HADOOP-1720

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to