gortiz commented on code in PR #10193:
URL: https://github.com/apache/pinot/pull/10193#discussion_r1138598152


##########
pinot-segment-spi/src/main/java/org/apache/pinot/segment/spi/index/IndexService.java:
##########
@@ -0,0 +1,83 @@
+/**
+ * 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.pinot.segment.spi.index;
+
+import com.google.common.collect.Sets;
+import java.util.HashSet;
+import java.util.Optional;
+import java.util.ServiceLoader;
+import java.util.Set;
+
+
+/**
+ * This is the entry point of the Index SPI.
+ *
+ * Ideally, if we used some kind of injection system, this class should be 
injected into a Pinot context all classes can
+ * receive when they are built. Given that Pinot doesn't have that, we have to 
relay on static fields.
+ *
+ * By default, this class will be initialized by reading all ServiceLoader SPI 
services that implement
+ * {@link IndexPlugin}, adding all the {@link IndexType} that can be found in 
that way.
+ *
+ * In case we want to change the instance to be used at runtime, the method 
{@link #setInstance(IndexService)} can be
+ * called.
+ */
+public class IndexService {
+
+  private static volatile IndexService _instance = fromServiceLoader();
+
+  private final Set<IndexType<?, ?, ?>> _allIndexes;
+
+  public IndexService(Set<IndexPlugin<?>> allPlugins) {
+    _allIndexes = Sets.newHashSetWithExpectedSize(allPlugins.size());
+
+    for (IndexPlugin<?> plugin : allPlugins) {
+      _allIndexes.add(plugin.getIndexType());
+    }
+  }
+
+  public static IndexService getInstance() {
+    return _instance;
+  }
+
+  public static void setInstance(IndexService other) {
+    _instance = other;
+  }
+
+  public static IndexService fromServiceLoader() {
+    Set<IndexPlugin<?>> pluginList = new HashSet<>();
+    for (IndexPlugin indexPlugin : ServiceLoader.load(IndexPlugin.class)) {
+      pluginList.add(indexPlugin);
+    }
+    return new IndexService(pluginList);
+  }
+
+  public Set<IndexType<?, ?, ?>> getAllIndexes() {
+    return _allIndexes;
+  }
+
+  public Optional<IndexType<?, ?, ?>> get(String indexId) {
+    return getAllIndexes().stream().filter(indexType -> 
indexType.getId().equalsIgnoreCase(indexId)).findAny();

Review Comment:
   > return map.values() instead?
   
   map.values() is a collection, not a set.
   
   > Also, looks like the indexType's id is the unique identifier for the index 
type. Should we onverride equals and hashCode of the class to only include id?
   
   That is a complex question that may deserve a discussion, but that actually 
doesn't matter in a scenario where there are more than one implementation for a 
given index type id, what I'm calling index overriding. I don't know if this is 
something we expect to have soon, so I don't know if this is actually important.
   
   The thing is, if we choose to define equality as "id is the same" and we 
have two different implementations in the classpath... the effects may be 
complex to analyze. Code in this branch doesn't actually use it that much, but 
other PRs will heavily use IndexType as hash map keys. 
   
   As said, given that I don't think we are going to support index overriding, 
I guess we can add the equality check.
   



-- 
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: commits-unsubscr...@pinot.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@pinot.apache.org
For additional commands, e-mail: commits-h...@pinot.apache.org

Reply via email to