[
https://issues.apache.org/jira/browse/CALCITE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16840357#comment-16840357
]
Hongze Zhang edited comment on CALCITE-3069 at 5/15/19 12:52 PM:
-----------------------------------------------------------------
I happened to have a ongoing work on the extensibility of Framework API, see
the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding
some more options accordingly to CalciteConnectionConfig, as well as to
Framework API, afterwards I gave up because I got inclined to treat the JDBC
layer more user-oriented, whereas the Framework API is more developer-oriented.
So I think it is better not to expose too much low level details in the former
at this time (but not 100% sure, if we think having those options configurable
via JDBC is also important I'll make further changes for it).
Also, in an architectural sense I think the implementation of Calcite JDBC can
be integrated with Framework API / Planner API. These APIs are well tested but
not used by Calcite itself, even currently you can find the Framework API calls
JDBC API internally, where I'll suggest to do things reversely such as forcing
Calcite JDBC to use Planner, that might be a lot of work but seems to be
reasonable to do.
[1] https://github.com/apache/calcite/pull/1145
was (Author: zhztheplayer):
I happened to have a ongoing work on the extensibility of Framework API, see
the PR[1] under CALCITE-2866. To solve that issue, earlier I used to try adding
some more options accordingly to CalciteConnectionConfig, as well as to
Framework API, afterwards I gave up because I got inclined to treat the JDBC
layer more user-oriented, whereas the Framework API is more developer-oriented.
So I think it is better not to expose too much low level details in the former
at this time (but not 100% sure, if we think having things configurable via
JDBC is also important I'll make further changes for it).
Also, in an architectural sense I think the implementation of Calcite JDBC can
be integrated with Framework API / Planner API. These APIs are well tested but
not used by Calcite itself, even currently you can find the Framework API calls
JDBC API internally, where I'll suggest to do things reversely such as forcing
Calcite JDBC to use Planner, that might be a lot of work but seems to be
reasonable to do.
[1] https://github.com/apache/calcite/pull/1145
> Make the JDBC Connection more extensible like the FrameworkConfig API
> ---------------------------------------------------------------------
>
> Key: CALCITE-3069
> URL: https://issues.apache.org/jira/browse/CALCITE-3069
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Affects Versions: 1.19.0
> Reporter: Lai Zhou
> Priority: Major
>
> More and more users are interested in building custom sql engines on top of
> Calcite.
> But for different sql engines, there're differences on sql parsing,
> expression conversions, implicit type casting ...even the physical
> implementations for logical plan.
> I think the FrameworkConfig API now provided a better way than JDBC
> Connection to custom these things.Are there any plans in the roadmap to
> enhance the JDBC Connection config , like FrameworkConfig API , to improve
> Calcite's extensibility ?
> Otherwise, implementing the whole physical plan like the default
> Enumerable-implementation will be boring , that also require a lot of work.
> May be we can do something to make the physical and execution plan(that says
> code-gen ) more customizable.
> Are there any thoughts on this issue?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
