geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Duling (JIRA)" <>
Subject [jira] [Resolved] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
Date Fri, 10 Jun 2016 16:40:21 GMT


Kevin Duling resolved GEODE-744.
       Resolution: Fixed
    Fix Version/s: 1.0.0-incubating.M3

Resolving this ticket as is.  Opening another for the {{count(*)}} issue.

> Incorrect use of APP_FETCH_SIZE in GFSH
> ---------------------------------------
>                 Key: GEODE-744
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: gfsh
>            Reporter: Jens Deppe
>            Assignee: Kevin Duling
>             Fix For: 1.0.0-incubating.M3
>         Attachments: workspace (1).zip
> A customer is facing an easily reproducible issue when executing queries from GFSH. It
appears that the APP_FETCH_SIZE is being set only when parts of the query are in lower case.
It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./".
> Exceute "./". This script inserts 1500 entries in the region and, afterwards, executes
two queries, one using lower case and other using upper case. You can see from the console
that ouput is different, one returns the actual size (1500) and the other one returns the
default APP_FETCH_SIZE (1000).
> Exceute "./".
> The fix seems pretty easy to implement, the method "addLimit" of the inner class "SelectExecStep?"
in "DataCommandFunction?" class should be modified to compare strings without using the actual
word case. Is not enough to add more "or" to the comparison like we are currently doing with
since keywords like "Count" or "coUn" will still break the functionallity. We should compare
everything using lower case or upper case, it doesn't matter which one, or at least make sure
that gfsh converts the query to upper/lower case before actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT")	query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}

This message was sent by Atlassian JIRA

View raw message