ableegoldman commented on code in PR #14648:
URL: https://github.com/apache/kafka/pull/14648#discussion_r1396551006


##########
streams/src/main/java/org/apache/kafka/streams/TopologyConfig.java:
##########
@@ -216,12 +232,38 @@ public TopologyConfig(final String topologyName, final 
StreamsConfig globalAppCo
         } else {
             storeType = globalAppConfigs.getString(DEFAULT_DSL_STORE_CONFIG);
         }
+
+        if (isTopologyOverride(DSL_STORE_SUPPLIERS_CLASS_CONFIG, 
topologyOverrides)) {
+            dslStoreSuppliers = getString(DSL_STORE_SUPPLIERS_CLASS_CONFIG);
+            log.info("Topology {} is overriding {} to {}", topologyName, 
DSL_STORE_SUPPLIERS_CLASS_CONFIG, dslStoreSuppliers);
+        } else {
+            dslStoreSuppliers = 
globalAppConfigs.getString(DSL_STORE_SUPPLIERS_CLASS_CONFIG);
+        }
     }
 
+    @Deprecated
     public Materialized.StoreType parseStoreType() {
         return MaterializedInternal.parse(storeType);
     }
 
+    /**
+     * @return the DslStoreSuppliers if the value was explicitly configured 
(either by
+     *         {@link StreamsConfig#DEFAULT_DSL_STORE} or {@link 
StreamsConfig#DSL_STORE_SUPPLIERS_CLASS_CONFIG})
+     */
+    public Optional<DslStoreSuppliers> resolveDslStoreSuppliers() {

Review Comment:
   > having the dslStoreSuppliers field be nullable 
   
   This is technically a different part of the code but on the subject of it 
being nullable... see 
https://github.com/apache/kafka/pull/14648#discussion_r1396543979
   
   Anyways I personally feel like it would be preferable to expose the 
globalAppConfigs over the entire thing, or better yet, something like this 
which at least kind of makes sense as a generally-useful public API:
   ```
   public boolean isGlobalOverride(final String config) {
       return globalAppconfigs.originals().containsKey(config);
   }
   ```
   Basically something that mirrors the `isTopologyOverride`, which presumably 
we also need. Just a thought. 



-- 
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: jira-unsubscr...@kafka.apache.org

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

Reply via email to