[jira] [Comment Edited] (CALCITE-506) Update EnumerableRelImplementor.stash so it is suitable for all kinds of classes

["Julian Hyde (JIRA)" <ji...@apache.org>]

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

Julian Hyde edited comment on CALCITE-506 at 12/9/14 11:58 PM:
---------------------------------------------------------------

{quote}How would you implement MongoToEnumerableConverter without EnumerableRelImplementor?{quote}

OK, you proved your point. EnumerableRelImplementor is a public API.

That said, I'd love people to be able to write adapters without getting their hands dirty with the enumerable convention. The Mongo adapter is a good example. There's no advantage to generating Java; its performance would not be affected if it was implemented as an interpreter. Then what you pass to it is not a pre-computed string but (a copy of) the root RelNode.

{quote}EnumerableImplementor detects such OTHER literals and passes it via DataContext transparently to the user.  Would this qualify as proper usage of OTHER sql type?{quote}

Yes, I guess so. I didn't have a specific purpose in mind for OTHER.

I do worry a bit about promising to handle arbitrary data types. We want to be able to generate a plan on node 1 and execute it on node 2. That means that all objects we pass between planner and executor have to be serializable or externalizable.


was (Author: julianhyde):
.bq How would you implement MongoToEnumerableConverter without EnumerableRelImplementor?

OK, you proved your point. EnumerableRelImplementor is a public API.

That said, I'd love people to be able to write adapters without getting their hands dirty with the enumerable convention. The Mongo adapter is a good example. There's no advantage to generating Java; its performance would not be affected if it was implemented as an interpreter. Then what you pass to it is not a pre-computed string but (a copy of) the root RelNode.

.bq EnumerableImplementor detects such OTHER literals and passes it via DataContext transparently to the user.  Would this qualify as proper usage of OTHER sql type?

Yes, I guess so. I didn't have a specific purpose in mind for OTHER.

I do worry a bit about promising to handle arbitrary data types. We want to be able to generate a plan on node 1 and execute it on node 2. That means that all objects we pass between planner and executor have to be serializable or externalizable.

> Update EnumerableRelImplementor.stash so it is suitable for all kinds of classes
> --------------------------------------------------------------------------------
>
>                 Key: CALCITE-506
>                 URL: https://issues.apache.org/jira/browse/CALCITE-506
>             Project: Calcite
>          Issue Type: Bug
>    Affects Versions: 1.0.0-incubating
>            Reporter: Vladimir Sitnikov
>            Assignee: Julian Hyde
>              Labels: newbie
>
> {code:java}
>   public Expression stash(RelNode child, Class clazz) {
>     final ParameterExpression x = register(child, clazz);
>     final Expression e = Expressions.call(getRootExpression(),
>         BuiltInMethod.DATA_CONTEXT_GET.method, Expressions.constant(x.name));
>     return Expressions.convert_(e, clazz);
>   }
> {code}
> I would like to make two corrections here:
> 1) I think {{public <T> Expression st(T x, Class<? super T> clazz) \{}} should be better signature.
> 2) It makes sense to translate {{DATA_CONTEXT_GET}} as a store to a {{final}} local variable at the very start of {{public org.apache.calcite.linq4j.Enumerable bind(final org.apache.calcite.DataContext root0)}} method (see {{implementRoot}}), so at the usage time it is just a load of local variable, not a {{map.get}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)