[
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)
