XN137 commented on code in PR #2015: URL: https://github.com/apache/polaris/pull/2015#discussion_r2200082893
########## polaris-core/src/main/java/org/apache/polaris/core/config/RealmConfigImpl.java: ########## @@ -0,0 +1,54 @@ +/* + * 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.polaris.core.config; + +import jakarta.annotation.Nullable; +import org.apache.polaris.core.context.RealmContext; +import org.apache.polaris.core.entity.CatalogEntity; + +public class RealmConfigImpl implements RealmConfig { + + private final PolarisConfigurationStore configurationStore; Review Comment: > Not having to deal with realms is definitely a great improvement, agreed. if you agree with that, don't you also agree that having "realm-scoped wrappers" around "multi-realm implementation details" simplifies code that operates strictly within a single realm? > But my concern remains that this new class becomes the de facto “Polaris Configuration Store” and this redundancy does not improve clarity. it is just an interface for accessing realm-scoped configuration values. `RealmConfigImpl` is forwarding requests to the actual `PolarisConfigurationStore` under the hood. it does not replace or overtake the "storage aspect" of configuration values and is thus not redundant. would it help address your concern if we rename `RealmConfigImpl` to `StoreForwardingRealmConfig` ? or to `RealmScopedConfigurationStore` (even though it doesnt store anything by itself) ? > Furthermore, the proposed structure could be interpreted as implying that these configs are set per-realm (while PolarisConfigurationStore confits are not) when in fact this is not the case. all public methods of `PolarisConfigurationStore` take a `@Nonnull RealmContext` parameter as there can be realm-specific overrides which take precedence. so if we not only look at the name of the class but at its public api as a whole, it does indeed only allow retrieving configuration values per realm currently, as you can not retrieve any configuration value without providing a `RealmContext`. if you have concrete ideas how class-naming could improve the "clarity" and "interpretation" of the current suggestion please let me know. -- 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: issues-unsubscr...@polaris.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
