The way I read this is: One is limiting on the server side, the other is limiting the client side. IOW within the query string is acting on server side.
On Tue, Jul 11, 2017 at 11:19 AM, Jinmei Liao <[email protected]> wrote: > 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 > -- ~/William
