[
https://issues.apache.org/jira/browse/CALCITE-4539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17303651#comment-17303651
]
James Starr commented on CALCITE-4539:
--------------------------------------
[~julianhyde], Janino is much faster compared to using java reflections.
However, my company reverted the update with Janino back when it was release
because it introduced other problems, such as OoM due relmeta data cached
growing too large. We currently use a soft reference cache in a custom copy of
CachingRelMetadataProvider in our own code base. We also have custom patches
for metadata invalidation in our custom branch of calcite, which I believe are
fixed in calcite master with other changes.
So, I am purposing a shim(HandleProvider) that is parameterized to the
prototype RelMetadataQuery, which would subsume most RelMetadataQueryBase and
provide a point for intercepting calls to the Janino compiler. This would
allow people to implement their custom metadata generation behavior in their
own code base instead of calcite main.
[~julianhyde], If you have chance, I would appreciate if you looked at my patch
and comment if you think once cleaned up would this approach be accepted.
> 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: 10m
> 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
> porptions of it a scattered through out various class and are frequently not
> extensible.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
