[
https://issues.apache.org/jira/browse/CALCITE-584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14305963#comment-14305963
]
Vladimir Sitnikov edited comment on CALCITE-584 at 2/4/15 9:10 PM:
-------------------------------------------------------------------
*-1 for scannable*
We need to come up with "better than queryable" interface and go with it.
1) Scannable/Projectable/etc are not optimizer-friendly (there is no cost based
support for it)
2) Scannable/Projectable are not optimization-friendly (there is no easy way to
optimize Object[] box-unboxing)
3) S/P are not developer-friendly since there is no easy way to return
Employee.class, or just plain Enumerable<Integer>.
{quote}A use case would be to read a relation from an HTTP table:
select * from
table(web('http://en.wikipedia.org/wiki/List_of_lakes_by_area')){quote}
Usage of "table *macro*" is *not* justified here. Can you justify it?
This use case should be implemented as a table function. Period.
See "multiplication strings" example:
https://github.com/apache/incubator-calcite/blob/341bdd8e2e1a48165652bab1d6341ef4d09e2523/core/src/test/java/org/apache/calcite/test/JdbcTest.java#L590-623
It has almost _zero_ boilerplate, except of awkward "queryable" interface (it
is not that obvious how to implement it, but BaseQueryable works without a
glitch).
Otherwise it seamlessly supports Object[] and custom provided row types (see
https://github.com/apache/incubator-calcite/blob/341bdd8e2e1a48165652bab1d6341ef4d09e2523/core/src/test/java/org/apache/calcite/test/JdbcTest.java#L540)
was (Author: vladimirsitnikov):
*-1 for scannable*
We need to came up with "better than queryable" interface and go with it.
1) Scannable/Projectable/etc are not optimizer-friendly (there is no cost based
support for it)
2) Scannable/Projectable are not optimization-friendly (there is no easy way to
optimize Object[] box-unboxing)
3) S/P are not developer-friendly since there is no easy way to return
Employee.class, or just plain Enumerable<Integer>.
{quote}A use case would be to read a relation from an HTTP table:
select * from
table(web('http://en.wikipedia.org/wiki/List_of_lakes_by_area')){quote}
Usage of "table *macro*" is *not* justified here. Can you justify it?
This use case should be implemented as a table function. Period.
See "multiplication strings" example:
https://github.com/apache/incubator-calcite/blob/341bdd8e2e1a48165652bab1d6341ef4d09e2523/core/src/test/java/org/apache/calcite/test/JdbcTest.java#L590-623
It has almost _zero_ boilerplate, except of awkward "queryable" interface (it
is not that obvious how to implement it, but BaseQueryable works without a
glitch).
Otherwise it seamlessly supports Object[] and custom provided row types (see
https://github.com/apache/incubator-calcite/blob/341bdd8e2e1a48165652bab1d6341ef4d09e2523/core/src/test/java/org/apache/calcite/test/JdbcTest.java#L540)
> Allow TableMacro to return Table other than TranslatableTable
> -------------------------------------------------------------
>
> Key: CALCITE-584
> URL: https://issues.apache.org/jira/browse/CALCITE-584
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> The TableMacro.apply method used to return Table but in
> https://github.com/apache/incubator-calcite/commit/aa1f0983c126c23466deb990c96d6ff2dffd908c
> this changed to TranslatableTable. It seems reasonable to allow TableMacro
> to return other sub-types of Table, for example ScannableTable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
