jacques-n commented on a change in pull request #2653: URL: https://github.com/apache/calcite/pull/2653#discussion_r774078632
########## File path: core/src/main/java/org/apache/calcite/rel/metadata/ProxyingMetadataHandlerProvider.java ########## @@ -0,0 +1,114 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to you under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.calcite.rel.metadata; + +import org.apache.calcite.rel.RelNode; + +import java.lang.reflect.Field; +import java.lang.reflect.InvocationHandler; +import java.lang.reflect.Method; +import java.lang.reflect.ParameterizedType; +import java.lang.reflect.Proxy; +import java.lang.reflect.Type; +import java.util.Arrays; +import java.util.List; +import java.util.Locale; +import java.util.Map; +import java.util.Objects; +import java.util.stream.Collectors; + +/** + * A MetadataHandlerProvider built on a RelMetadataProvider. + * + * Uses proxies to call the underlying metadata provider. + */ +public class ProxyingMetadataHandlerProvider implements MetadataHandlerProvider { + + private final RelMetadataProvider provider; + + /** + * Create a proxying handler provider. + * @param provider The provider this will operate against. + */ + public ProxyingMetadataHandlerProvider(RelMetadataProvider provider) { + this.provider = provider; + } + + @SuppressWarnings("deprecation") + @Override public <MH extends MetadataHandler<?>> MH handler(Class<MH> handlerClass) { + + Type[] types = handlerClass.getGenericInterfaces(); + if (types.length != 1 || !(types[0] instanceof ParameterizedType)) { + throw new UnsupportedOperationException("Unexpected failure. " + handlerClass); + } + + ParameterizedType pType = (ParameterizedType) types[0]; + if (pType.getRawType() != MetadataHandler.class) { + throw new UnsupportedOperationException("Unexpected failure. " + handlerClass); + } + Class<?> metadataType = (Class<?>) pType.getActualTypeArguments()[0]; + final Field field; + final MetadataDef<?> def; + try { + field = metadataType.getField("DEF"); + def = Objects.requireNonNull((MetadataDef<?>) field.get(null), + () -> "Unexpected failure. " + handlerClass); + } catch (NoSuchFieldException | IllegalAccessException e) { + throw new RuntimeException(e); + } + + List<Method> methods = def.methods; + Map<String, Method> methodMap = methods.stream() + .collect(Collectors.toMap(Method::getName, f -> f)); + InvocationHandler handler = (proxy, method, args) -> { + Method metadataMethod = Objects.requireNonNull(methodMap.get(method.getName()), + () -> "Not supported: " + method); + RelNode rel = Objects.requireNonNull((RelNode) args[0], "rel must be non null"); + RelMetadataQuery mq = Objects.requireNonNull((RelMetadataQuery) args[1], + "mq must be non null"); + + // using deprecated RelMetadataProvider method here as the non-deprecated methods completely + // sidestep the purpose of RelMetadataProvider reflection-based functionality. + UnboundMetadata metadata = provider.apply( + (Class<? extends RelNode>) rel.getClass(), + (Class<? extends Metadata>) metadataType); Review comment: This isn't my favorite either but I think it's the right choice for now. The apis are so much in flux at the moment that reverting deprecation isn't ideal since I'm not convinced that the deprecated interface is best either. (In a perfect world, we would have included the second impl before deciding to deprecate this method.) A risk associated with the ongoing refactor in this module is too much focus on a single impl (the janino one). It's important to have this second impl in place so we can make sure the refactoring makes sense across impls. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
