[jira] [Assigned] (CALCITE-4879) Make RelMetadataQuery abstract

["Jacques Nadeau (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jacques Nadeau reassigned CALCITE-4879:
---------------------------------------

    Assignee: Jacques Nadeau

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