[
https://issues.apache.org/jira/browse/HBASE-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357815#comment-15357815
]
Appy commented on HBASE-15965:
------------------------------
[~junegunn]
The idea here is that *interactive* are user-facing things and might change
substantially between releases to improve the user experience. See it as
functionality + formatting.
In contrast, *non-interactive* are meant to be used when building scripts using
hbase shell's output.
You should be able to get the return value using -n (non-interactive) flag.
bq. Actually I was thinking of further extending the return values to contain
more information
Every change [breaks someone's workflow|https://xkcd.com/1172/]. Changing
return value to contain more information *will* break someone else's workflow
(who's manually parsing shell output). The idea above is, let's at least give
users a more stable way of building on top of shell by removing their
dependency on how shell format's data.
bq. How about if we add an extra set of "query" commands (e.g. get_tables or
maybe tables?) that return values regardless of interactivity?
That approach requires duplicating classes and we over 100 commands, not good
from dev perspective. It'll be a mess from user perspective too. Imaging about
200 commands, some of which are basically just like others. I don't feel that
extra set of commands is the right way to design this because there will be
naming consistency issues, extra maintenance cost, etc. And then comes the
issue of compatibility guarantees. Ideally, stuff users use to build their own
scripts should have better compat guarantees. It's far easier to have different
compat guarantees for two different modes than different compat guarantees for
different commands.
So i'd really like to not go this path.
I'm more inclined to two mode approach, because it'll make things far easier
for users. If you see a problem or a case not being handled, lets discuss it
and come up with even better solution.
> Shell test changes. Use @shell.command instead directly calling functions in
> admin.rb and other libraries.
> ----------------------------------------------------------------------------------------------------------
>
> Key: HBASE-15965
> URL: https://issues.apache.org/jira/browse/HBASE-15965
> Project: HBase
> Issue Type: Bug
> Reporter: Appy
> Assignee: Appy
> Fix For: 2.0.0
>
> Attachments: HBASE-15965.master.001.patch,
> HBASE-15965.master.002.patch, HBASE-15965.master.003.patch
>
>
> Testing by executing a command will cover the exact path users will trigger,
> so its better then directly calling library functions in tests. Changing the
> tests to use @shell.command(:<command>, args) to execute them like it's a
> command coming from shell.
> Norm change:
> Commands should print the output user would like to see, but in the end,
> should also return the relevant value. This way:
> - Tests can use returned value to check that functionality works
> - Tests can capture stdout to assert particular kind of output user should
> see.
> - We do not print the return value in interactive mode and keep the output
> clean. See Shell.command() function.
> Bugs found due to this change:
> - Uncovered bug in major_compact.rb with this approach. It was calling
> admin.majorCompact() which doesn't exist but our tests didn't catch it since
> they directly tested admin.major_compact()
> - Enabled TestReplicationShell. If it's bad, flaky infra will take care of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
