jnaous commented on a change in pull request #9111: Add HashJoinSegment, a virtual segment for joins. URL: https://github.com/apache/druid/pull/9111#discussion_r365280971
########## File path: processing/src/main/java/org/apache/druid/segment/ColumnProcessorFactory.java ########## @@ -0,0 +1,57 @@ +/* + * 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.druid.segment; + +import org.apache.druid.query.dimension.ColumnSelectorStrategyFactory; +import org.apache.druid.query.dimension.VectorColumnProcessorFactory; +import org.apache.druid.segment.column.ValueType; + +/** + * Class that encapsulates knowledge about how to create "column processors", which are... objects that process columns + * and want to have type-specific logic. Used by {@link ColumnProcessors#makeProcessor}. + * + * Column processors can be any type "T". The idea is that a ColumnStrategizer embodies the logic for wrapping + * and processing selectors of various types, and so enables nice code design, where type-dependent code is not + * sprinkled throughout. + * + * @see VectorColumnProcessorFactory the vectorized version + * @see ColumnProcessors#makeProcessor which uses these, and which is responsible for + * determining which type of selector to use for a given column + * @see ColumnSelectorStrategyFactory which serves a similar purpose and may be replaced by this in the future + * @see DimensionHandlerUtils#createColumnSelectorPluses which accepts {@link ColumnSelectorStrategyFactory} and is + * similar to {@link ColumnProcessors#makeProcessor} + */ +public interface ColumnProcessorFactory<T> +{ + /** + * This default type will be used when the underlying column has an unknown type. + */ + ValueType defaultType(); + + T makeDimensionProcessor(DimensionSelector selector); + + T makeFloatProcessor(BaseFloatColumnValueSelector selector); + + T makeDoubleProcessor(BaseDoubleColumnValueSelector selector); + + T makeLongProcessor(BaseLongColumnValueSelector selector); + + T makeComplexProcessor(BaseObjectColumnValueSelector<?> selector); +} Review comment: I'm curious why we don't use Guice for these types of things. I assume because using Guice factories is expensive? The nice thing would be it would centralize the place where we add new supported types... ---------------------------------------------------------------- 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. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
