[
https://issues.apache.org/jira/browse/CALCITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Starr updated CALCITE-4539:
---------------------------------
Description:
Calcite janino backed metadata does not support all the functionality that the
java reflection backed metadata system, such as customizing the cache to use
soft refs or have a max size. Furthermore, the janino backed metadata provider
has many opinion that other are not universally shared, such as lazy loading,
requiring all rels to registered to a global singleton, use of thread locals.
There is no easy way to currently override these opinions.
Calcites metadata system should consist of 3 APIs: metadata consumer, metadata
implementors, metadata behavior. The metadata consumer need to able to fetch
the appropriate metadata and invalidate the cache. Currently this is all done
through RelMetadataQuery with some very leaky abstractions. Metadata
implementors create functions that extract the metadata for particular node
types. These functions are registered via ReflectiveRelMetadataProvider and
ChainedRelMetadataProvider. Attempting to configure the internal behavior does
not currently have an api. Currently portions of it a scattered through out
various class and are frequently not extensible. These could all be
concentrated in a single class MetadataHandlerProvider, to allow for
configuration of eager/lazy loading behavior, caching policy(thread safe, max
size, soft references), or a clear api for some to go their own way for handler
generation.
was:
Calcite janino backed metadata does not support all the functionality that the
java reflection backed metadata system, such as customizing the cache to use
soft refs or have a max size. Furthermore, the janino backed metadata provider
has many opinion that other are not universally shared, such as lazy loading,
requiring all rels to registered to a global singleton, use of thread locals.
There is no easy way to currently override these opinions.
Calcites metadata system should consist of 3 APIs: metadata consumer, metadata
implementors, metadata behavior. The metadata consumer need to able to fetch
the appropriate metadata and invalidate the cache. Currently this is all done
through RelMetadataQuery with some very leaky abstractions. Metadata
implementors create functions that extract the metadata for particular node
types. These functions are registered via ReflectiveRelMetadataProvider and
ChainedRelMetadataProvider. Attempting to configure the internal behavior does
not currently have an api. Currently portions of it a scattered through out
various class and are frequently not extensible. These could all be
concentrated in a single class
> Support pluggable metadata handlers and caching
> -----------------------------------------------
>
> Key: CALCITE-4539
> URL: https://issues.apache.org/jira/browse/CALCITE-4539
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: James Starr
> Priority: Major
> Labels: pull-request-available
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calcite janino backed metadata does not support all the functionality that
> the java reflection backed metadata system, such as customizing the cache to
> use soft refs or have a max size. Furthermore, the janino backed metadata
> provider has many opinion that other are not universally shared, such as lazy
> loading, requiring all rels to registered to a global singleton, use of
> thread locals. There is no easy way to currently override these opinions.
> Calcites metadata system should consist of 3 APIs: metadata consumer,
> metadata implementors, metadata behavior. The metadata consumer need to able
> to fetch the appropriate metadata and invalidate the cache. Currently this
> is all done through RelMetadataQuery with some very leaky abstractions.
> Metadata implementors create functions that extract the metadata for
> particular node types. These functions are registered via
> ReflectiveRelMetadataProvider and ChainedRelMetadataProvider. Attempting to
> configure the internal behavior does not currently have an api. Currently
> portions of it a scattered through out various class and are frequently not
> extensible. These could all be concentrated in a single class
> MetadataHandlerProvider, to allow for configuration of eager/lazy loading
> behavior, caching policy(thread safe, max size, soft references), or a clear
> api for some to go their own way for handler generation.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
