[ 
https://issues.apache.org/jira/browse/DRILL-5318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15946217#comment-15946217
 ] 

ASF GitHub Bot commented on DRILL-5318:
---------------------------------------

Github user sohami commented on a diff in the pull request:

    https://github.com/apache/drill/pull/788#discussion_r108563545
  
    --- Diff: 
exec/java-exec/src/test/java/org/apache/drill/test/QueryBuilder.java ---
    @@ -271,6 +276,91 @@ public QuerySummary run() throws Exception {
       }
     
       /**
    +   * Run the query and return the first result set as a
    +   * {@link DirectRowSet} object that can be inspected directly
    +   * by the code using a {@link RowSetReader}.
    +   * <p>
    +   * An enhancement is to provide a way to read a series of result
    +   * batches as row sets.
    +   * @return a row set that represents the first batch returned from
    +   * the query
    +   * @throws RpcException if anything goes wrong
    +   */
    +
    +  public DirectRowSet rowSet() throws RpcException {
    +
    +    // Ignore all but the first non-empty batch.
    +
    +    QueryDataBatch dataBatch = null;
    +    for (QueryDataBatch batch : results()) {
    +      if (dataBatch == null  &&  batch.getHeader().getRowCount() != 0) {
    +        dataBatch = batch;
    +      } else {
    +        batch.release();
    +      }
    +    }
    +
    +    // No results?
    +
    +    if (dataBatch == null) {
    +      return null;
    +    }
    +
    +    // Unload the batch and convert to a row set.
    +
    +    final RecordBatchLoader loader = new 
RecordBatchLoader(client.allocator());
    +    try {
    +      loader.load(dataBatch.getHeader().getDef(), dataBatch.getData());
    +      dataBatch.release();
    +      VectorContainer container = loader.getContainer();
    +      container.setRecordCount(loader.getRecordCount());
    +      return new DirectRowSet(client.allocator(), container);
    +    } catch (SchemaChangeException e) {
    +      throw new IllegalStateException(e);
    +    }
    +  }
    +
    +  /**
    +   * Run the query that is expected to return (at least) one row
    +   * with the only (or first) column returning a long value.
    +   *
    +   * @return the value of the first column of the first row
    +   * @throws RpcException if anything goes wrong
    +   */
    +
    +  public long singletonLong() throws RpcException {
    +    RowSet rowSet = rowSet();
    +    if (rowSet == null) {
    +      throw new IllegalStateException("No rows returned");
    +    }
    +    RowSetReader reader = rowSet.reader();
    +    reader.next();
    +    long value = reader.column(0).getLong();
    --- End diff --
    
    Can we please refactor the common portion in singletonLong and singletonInt 
? Since I guess in future if we support retrieving more types then again it 
will be repeated?


> Create a sub-operator test framework
> ------------------------------------
>
>                 Key: DRILL-5318
>                 URL: https://issues.apache.org/jira/browse/DRILL-5318
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Tools, Build & Test
>    Affects Versions: 1.11.0
>            Reporter: Paul Rogers
>            Assignee: Paul Rogers
>             Fix For: 1.11.0
>
>         Attachments: Sub-OperatorTestFramework.pdf
>
>
> Drill provides two unit test frameworks for whole-server, SQL-based testing: 
> the original {{BaseTestQuery}} and the newer {{ClusterFixture}}. Both use the 
> {{TestBuilder}} mechanism to build system-level functional tests that run 
> queries and check results.
> Jason provided an operator-level test framework based, in part on mocks: 
> As Drill operators become more complex, we have a crying need for true 
> unit-level tests at a level below the whole system and below operators. That 
> is, we need to test the individual pieces that, together, form the operator.
> This umbrella ticket includes a number of tasks needed to create the 
> sub-operator framework. Our intention is that, over time, as we find the need 
> to revisit existing operators, or create new ones, we can employ the 
> sub-operator test framework to exercise code at a finer granularity than is 
> possible prior to this framework.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to