[
https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453519#comment-17453519
]
Jacques Nadeau commented on CALCITE-4879:
-----------------------------------------
I'm wondering if there is a disconnect between the current state of the code
and what the original intentions may have been. I'd like to state a few basic
assertions to make sure we're working from the same foundation.
Assertion #1: RelMetadataQuery is hardcoded to force the use of Janino.
Assertion #2: RelMetadataQuery has a bunch of specific behavior implemented
within it based on the concept of handler revision.
Assertion #3: Handler revision isn't related to RelMetadataProvider and is a
Janino-specific concept.
Assertion #4: There are several fields exposed on the public API of
RelMetadataQuery (via RelMetadataQueryBase) that are internal and shouldn't be
exposed to consumers/users of RelMetdataQuery.
Do people agree with these assertions?
Once we are aligned on consistent foundation, we can further discuss possible
changes.
> 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)
