[
https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17454151#comment-17454151
]
Jacques Nadeau commented on CALCITE-4879:
-----------------------------------------
> Did you notice that we have a MetadataFactory that query the metadata using
> direct java call(not based on Janino) ?
Yes. Unfortunately, it isn't a substitute for RelMetadataQuery.
RelMetadataQuery is used extensively throughout the codebase (including by
numerous rules). Here is one concrete example:
[ProjectJoinRemoveRule|https://github.com/apache/calcite/blob/d70583c4a8013f878457f82df6dffddd71875900/core/src/main/java/org/apache/calcite/rel/rules/ProjectJoinRemoveRule.java#L106].
One cannot use this rule without having an implementation of RelMetadataQuery.
RelMetadataQuery is hard-coded to use Janino. This pattern repeats itself in a
large number of places. There is no way to "replace" RelMetadataQuery with
MetadataFactory in these situations (that I see).
Additionally, MetadataFactory is deprecated on RelOptCluster, AbstractRelNode
and isn't on the RelNode interface. The only implementation is also deprecated.
(For comparison,
[192|https://github.com/apache/calcite/search?q=RelMetadataQuery] Calcite files
reference RelMetadataQuery,
[4|https://github.com/apache/calcite/search?q=MetadataFactory] reference
RelMetadataFactory and 3 of those 4 have references that are specifically
deprecated.) Building a new system on MetadataFactory seems very much to
neither solve the problem at hand nor be a good idea given its deprecation.
Do you agree with 4 assertions above?
> Make RelMetadataQuery abstract
> ------------------------------
>
> Key: CALCITE-4879
> URL: https://issues.apache.org/jira/browse/CALCITE-4879
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Jacques Nadeau
> Assignee: Jacques Nadeau
> Priority: Major
>
> The RelOptCluster.setMetadataQuerySupplier() and RelMedataQuery abstraction
> are great at separating how planners and rules consume metadata versus how
> metadata is produced. While details about how metadata is produced is
> (mostly) not leaked in the api of RelMetadataQuery, the class does assume
> that metadata will be produced via the current mechanisms surrounding
> RelMetadataProviders and MetadataHandlers. This ticket targets separating the
> production of metadata from the consumption interface, by making
> RelMetadataQuery abstract (either as an abstract class or as a interface) and
> moving the handler and provider specific implementations to an implementation
> of RelMetadataQuery. This will allow a broader breadth of experimentation to
> be undertaken. For example, one example people have been evaluating is
> whether a lambda based system would be easier to understand and debug, as
> performant and more AOT friendly than the existing systems of chains and
> janino compilation.
> To accomplish this task, the first step will be to deprecate the existing
> constructors and inform people to use a concrete subtype. Once deprecated,
> the actual logic that currently exists in RelMetadataQuery can be extracted
> into the concrete subtype and the base class can be made either abstract or
> an interface (depending on what seems most appropriate at the time).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
