+1 Wayne Lund Advisory Platform Architect 916.296.1893 [email protected]
> On Jul 11, 2017, at 8:41 AM, Anthony Baker <[email protected]> wrote: > > It’s fairly common in query tooling to be able to set a result set limit. I > would make this a first class option within gfsh instead of an environment > variable. > > gfsh> set query-limit=1000 > > or > > gfsh> query --query='select * from /A’ --limit=1000 > > The result set limit is semantically different from specifying a LIMIT on the > OQL query itself. > > Anthony > >> On Jul 11, 2017, at 7:53 AM, William Markito Oliveira >> <[email protected] <mailto:[email protected]>> wrote: >> >> +1 for the combination of 1 and 2 as well. It would be interesting to >> explore at least a couple output formats, csv being one of the most common >> for people that wants to import or analyze the data using other tools. >> >> On Tue, Jul 11, 2017 at 8:31 AM, Michael Stolz <[email protected] >> <mailto:[email protected]>> wrote: >> Actually a really nice thing would be to put the pagination feature into the >> OQL engine where it belongs. Clients shouldn't have to implement pagination. >> >> -- >> Mike Stolz >> Principal Engineer, GemFire Product Manager >> Mobile: +1-631-835-4771 <tel:(631)%20835-4771> >> >> On Tue, Jul 11, 2017 at 12:00 AM, Michael William Dodge <[email protected] >> <mailto:[email protected]>> wrote: >> 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] >> > <mailto:[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 >> >> >> >> >> >> -- >> ~/William >
