[
https://issues.apache.org/jira/browse/CALCITE-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14946103#comment-14946103
]
Jinfeng Ni edited comment on CALCITE-911 at 10/7/15 1:05 AM:
-------------------------------------------------------------
I'll post a patch which includes the SimpleCalciteSchema.
As [~jnadeau] said, the caching code in CalciteSchema breaks almost every query
in Drill. If we could have a different implementation without the caching,
then it probably will solve our problem.
That's why I move code around interface / abstract class, to make CalciteSchema
to have different implementation. I'm not quite follow about [~julianhyde] api
concern : the method defined in the new interface are mostly public methods in
CalciteSchema, which is public class. Why is such change regarded as increase
api change ( public methods in public class vs. methods in interface). I
assume user of Calcite would see those methods in either cases.
was (Author: jni):
I'll post a patch which includes the SimpleCalciteSchema.
As [~jnadeau] said, the caching code in CalciteSchema breaks almost every query
in Drill. If we could have a different implementation without the caching,
then it probably will solve our problem.
That's why I move code around interface / abstract class, to make CalciteSchema
to have different implementation. I'm not quite follow about @Julianh's api
concern : the method defined in the new interface are mostly public methods in
CalciteSchema, which is public class. Why is such change regarded as increase
api change ( public methods in public class vs. methods in interface). I
assume user of Calcite would see those methods in either cases.
> Make CalciteSchema extendible for different implementation.
> -----------------------------------------------------------
>
> Key: CALCITE-911
> URL: https://issues.apache.org/jira/browse/CALCITE-911
> Project: Calcite
> Issue Type: Bug
> Reporter: Jinfeng Ni
> Assignee: Jinfeng Ni
>
> CalciteSchema by default uses cache to store table, sub-schema, function.
> This would work perfectly for schema-based system, yet would create problem
> for Drill, which dynamically explore the schema on the fly during query
> execution.
> One solution is to refactor CalciteSchema and make it as an interface. The
> default implementation would still use the current implementation. Further,
> it would other system to extend the default behavior and make CalciteSchema
> works for Drill as well.
> Background information: The issue around CalciteSchema is one of the reasons
> that Drill has to use a forked version of Calcite. Hopefully, if we could
> resolve this issue, we are one step further to remove the forked Calcite in
> the near future.
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
