[
https://issues.apache.org/jira/browse/CALCITE-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453525#comment-17453525
]
Jacques Nadeau commented on CALCITE-4879:
-----------------------------------------
As I have continued to think about this tonight, it struck me that one way to
probably clean up a lot of this is to move the revision concept inside Janino's
handlers rather than have them leak into RelMetdataQuery. At that point,
RelMetadataQuery could avoid the coupling with Janino and move to only relying
on RelMetadataProvider.
If Janino defined handler decorators that handled the revision concepts, that
could be contained entirely within the janino provider and no one else would
need to know about revision. (the reason that janino is hardcoded is because
RelMetadataQuery needs to know about revision).
> 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)
