[
https://issues.apache.org/jira/browse/OPTIQ-436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14176468#comment-14176468
]
Julian Hyde commented on OPTIQ-436:
-----------------------------------
I got the right issue. I fixed how the enumerable code-generation converts
between row types of Object[], Object, Row and <Synthetic class>. It's there in
https://github.com/julianhyde/optiq/commits/optiq-436. It might not solve
OPTIQ-397, but it's worth checking when I push to master.
> Simpler SPI to query Table
> --------------------------
>
> Key: OPTIQ-436
> URL: https://issues.apache.org/jira/browse/OPTIQ-436
> Project: Optiq
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> 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.
> {code}
> 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);
> }
> {code}
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)