what if user wants to do: gfsh> query --query='select * from /A limit 10' --limit=100
What's the difference between put it inside the query string or outside? I think eventually it's adding the limit clause to the query. On Tue, 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]> 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]> 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 <(631)%20835-4771> >> >> On Tue, Jul 11, 2017 at 12:00 AM, Michael William Dodge < >> [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]> 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 > > > -- Cheers Jinmei
