[CALCITE-436] Simpler SPI to query Table

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.9.2-incubating
• Assignee: Julian Hyde
• Reporter: Julian Hyde
• Created: 09/Oct/14 13:13
• Updated: 02/Sep/15 01:02
• Resolved: 28/Oct/14 17:53

Description

Currently, the easiest way for a Table to return results is to implement TranslatableTable, and in the toRel method return a RelNode. That RelNode is typically a sub-class of TableAccessRelBase and implements itself by generating Java code, which must be compiled an executed.

We propose an interfaces so that a Table can return results directly.

import net.hydromatic.avatica.Cursor;
import org.eigenbase.util.Pair;
import net.hydromatic.optiq.Table;
import org.eigenbase.rex.RexNode;
import org.eigenbase.reltype.RelDataTypeField;

interface CursorableTable extends Table {
  /** Returns a cursor over the rows in this Table. */
  Cursor scan();
}

interface ProjectableCursorableTable extends Table {
  /** Given a list of filters and a list of fields to project, returns a
   * cursor over the rows in this Table and a list of filters that it
   * could not implement.
   *
   * <p>The cursor must implement the projects and any filters not
   * in the list. */
  Pair<Cursor, List<RexNode>> projectFilterScan(List<RexNode> filters, List<RelDataTypeField> projects);
}

Cursor is a simple API to implement.

A table that implements the CursorableTable SPI does not need to implement TranslatableTable, and so can return its results without doing any code generation.

The ProjectableCursorableTable SPI is also optional and goes further; it allows Calcite to push down simple projects and filters without the Table implementor writing any rules or code-generation code. If the implementation of the SPI cannot handle a particular filter, it just returns it, and Calcite will add its own filter to implement it.

Issue Links

• is required by: CALCITE-445 Pull up filters rejected by a ProjectableFilterableTable