[
https://issues.apache.org/jira/browse/CALCITE-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14288940#comment-14288940
]
Vladimir Sitnikov commented on CALCITE-558:
-------------------------------------------
{quote}We've had lots of people say 'yuck' when they find that they have to
generate java code in order to write a connector to a data source like
mongo.{quote}
Current {{MongoToEnumerableConverter}} is like 100 lines long.
It does not look like a "yuck".
Well, it does, however the _major part_ of the mongo code is "passing non
literal ArrayList to linq4j".
"generate java code" part is not more than "tell Calcite to execute
{{MongoTable.aggregate(...)}}".
We never suggested moving all the code to linq4j part. On contrary, the idea
was use as little linq4j as it is possible and use upcalls to the java.
The "problem" can easily be solved if something like
{{EnumerableRelImplementor.result(Bindable impl, PhysType)}} is added.
If non-numeric, non-string literals were allowed in linq4j, then mongo code
would be just "Expressions.call(MONGO_QUERYABLE_AGGREGATE)}}" kind of thing
with no other "code generation" stuff.
It still makes sense to allow "passing of non-literal constant values to
linq4j" to simplify the life of those who do generate code.
So the mongo-to-enumerable adapter could go without any notion of
{{Expression/Expressions/BlockBuilder/etc}}.
Do you still think it worths reimplmenting the wheel just for that?
{quote}By the way, another nice thing about a true relational interpreter is
that you could envisage building a debugger on top of it,{quote}
The nice part of generation of java code is you _can_ have the generated code
in the bug reports.
Lots of people know how to read java, so it simplifies the analysis.
Having step-by-step debugging is a nice feature, however I belive IDE's can be
tricked to step-by-step through the generated code.
By the way: when I was implementing window functions support, I copied and
pasted the generated code and debugged it in the IDEA from times to times.
> Add BINDABLE convention and make it the default convention for query root
> -------------------------------------------------------------------------
>
> Key: CALCITE-558
> URL: https://issues.apache.org/jira/browse/CALCITE-558
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> The default convention is currently ENUMERABLE, which means that to execute a
> query, and in particular to use the JDBC driver, RelNodes need to be able to
> convert themselves to code. This introduces a lot of dependencies that make
> CALCITE-466 difficult to solve.
> We propose to add a new convention that can be more easily implemented by a
> RelNode, using an interpreter or otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
