[jira] [Comment Edited] (CALCITE-558) Add BINDABLE convention and make it the default convention for query root

["Vladimir Sitnikov (JIRA)" <ji...@apache.org>]

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

Vladimir Sitnikov edited comment on CALCITE-558 at 1/23/15 7:55 AM:
--------------------------------------------------------------------

{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 to use as little linq4j as it is possible and to upcall 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.



was (Author: vladimirsitnikov):
{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)