I prefer to redirect output to a file when there is any chance that the results might be huge. Thus I find the combination of #1 and #2 to be sufficient for me.
Sarge > On 10 Jul, 2017, at 17:13, Jinmei Liao <[email protected]> wrote: > > Hi, all gfsh-users, > > In our refactor week, we are trying to refactor how multi-step command is > implemented. The currently implementation is hard to understand to begin > with. The implementation breaks the OO design principals in multiple ways. > It's not thread-safe either. This is an internal command type, and and only > our "query" command uses it. > > This is how our current "query" command works: > 1) user issues a "query --query='select * from /A'" command, > 2) server retrieves the first 1000 (fetch-size, not configurable) rows, > 3) if the query mode is NOT interactive, it sends back all the result at one. > 4) if they query mode is interactive, it sends the first 20 (page-size, not > configurable) records. and user uses "n" to go to the next page, once it hits > the last page (showing all 1000 record or get to the end of the result set), > the command finishes. > > we would like to ask how useful is this interactive feature. Is it critical > for you? Would the following simplification be sufficient? > > 1) query command always returns the entire fetch size. We can make it > configurable through environment variables, default to be 100, and you can > also reset it in each individual query command using "query --query='select * > from /A limit 10' > > 2) provide an option for you to specify a file where we can dump all the > query result in and you can use shell pagination to list the content of the > file. > > Please let us know your thoughts/comments. Thanks! > > > -- > Cheers > > Jinmei
