vdiravka commented on a change in pull request #1345: DRILL-6494: Drill Plugins Handler URL: https://github.com/apache/drill/pull/1345#discussion_r199359807
########## File path: exec/java-exec/src/main/java/org/apache/drill/exec/store/StoragePluginsHandler.java ########## @@ -0,0 +1,40 @@ +/* + * 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.drill.exec.store; + +import org.apache.drill.common.logical.StoragePluginConfig; +import org.apache.drill.exec.planner.logical.StoragePlugins; +import org.apache.drill.exec.store.sys.PersistentStore; + + +/** + * Storage plugins handler is an additional service for updating storage plugins configs from the file + */ +public interface StoragePluginsHandler { + + /** + * Update incoming storage plugins configs from persistence store if present, otherwise bootstrap plugins configs. + * One of the params should be null, second shouldn't + * + * @param persistentStore the last storage plugins configs from persistence store + * @param bootstrapPlugins bootstrap storage plugins, which are used in case of first Drill start up + * @return all storage plugins, which should be loaded into persistence store + */ + void loadPlugins(PersistentStore<StoragePluginConfig> persistentStore, StoragePlugins bootstrapPlugins); Review comment: Let's say the current approach is method1 and the approach of transferring the all configs from PS to handler is method2. So for both of them the first stage is common: 1. Getting the iterator and check for any element - `pluginSystemTable.getAll().hasNext()`, which is used to detect whether any plugins are present in PStore or this is the first set-up. 2. Then for method 2 I need to extract every plugin configs and put it to the `StoragePlugins` - N calls to PStore. For method 1 I need pass just reference to PStore. 3. For method2 I need to update plugins and to determine only updated plugins configs to put them to PStore - <= N calls. Similar in method1 I need to get new plugins if exist and put them to PStore - <= N calls. _________________________________________ The benefit in the second stage. I agree with you regarding registry responsibilities. But current approach is also good: anyway currently `StoragePluginsHandler` instance is a part of `StoragePluginRegistryImpl` and also loading configs is better from code understanding point of view than updating and returning different results for different modes (you can compare with changes from the first commit). ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
