You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Stamatis Zampetakis (Jira)" <ji...@apache.org> on 2019/10/18 07:09:00 UTC

[jira] [Commented] (CALCITE-3425) Inconsistent behavior of MetadataProvider in RelOptCluster

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

Stamatis Zampetakis commented on CALCITE-3425:
----------------------------------------------

I also noticed this a while ago and I agree it brings confusion. It seems more natural to be part of the {{RelOptCluster}}. Moreover I am not a big fan of the ThreadLocal variable used in that way for configuration purposes.

> Inconsistent behavior of MetadataProvider in RelOptCluster
> ----------------------------------------------------------
>
>                 Key: CALCITE-3425
>                 URL: https://issues.apache.org/jira/browse/CALCITE-3425
>             Project: Calcite
>          Issue Type: Improvement
>          Components: core
>            Reporter: Haisheng Yuan
>            Priority: Major
>
> To use customized metadata provider, we can do the following:
> {code:java}
> RelMetadataQuery.THREAD_PROVIDERS.set(
>       JaninoRelMetadataProvider.of(xxxmetadataProvider));
> {code}
> It only works for builtin metadata type, but for customized metadata, we still get exception when retrieve the metadata using reflection. Because when the RelOptCluster is created, it always use the default metadata provider, instead of the customized one.
> {code:java}
> setMetadataProvider(DefaultRelMetadataProvider.INSTANCE);
> {code}
> It causes confusing. We have to set the provider in 2 places. Should we unify them in a single place?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)