[ 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)