Package com.linkedin.venice.controller.storeconfig

Class StoreConfigUpdater

java.lang.Object

com.linkedin.venice.controller.storeconfig.StoreConfigUpdater

public final class StoreConfigUpdater
extends Object

Holds the parallel update-store implementations lifted out of VeniceHelixAdmin (child-side, mutates the store directly) and VeniceParentHelixAdmin (parent-side, writes an UPDATE_STORE admin message). Both methods are mechanical lifts of their originals — every implicit this.X() call is rewritten as admin.X(), and helper visibilities on the admins were widened where needed (some have since been narrowed back to package-private now that this class is the sole external caller). The bodies are not quite byte-identical to their originals anymore: the partitioner-merge, lifecycle-hooks validation, and hybrid-config merge are delegated to PartitionerConfigPolicy, StoreLifecycleHooksPolicy, and HybridStoreConfigPolicy respectively, rather than inlined. The two bodies are kept in the same file so future deduplication of the shared param-unpacking and validation has both versions in one place.

Suggested structural follow-up before the dedup: replace the VeniceHelixAdmin / VeniceParentHelixAdmin parameter with a narrow StoreConfigMutator interface containing only the setters and helpers this class actually calls (setStoreOwner, setStoreReadability, storeMetadataUpdate, getPubSubTopicRepository, getMultiClusterConfigs, etc.), implemented by both admins. The current shape — applyOnChild(this, ...) / applyOnParent(this, ...) — passes the entire admin in, which the Venice style guide explicitly discourages ("Avoid passing this into classes … consider whether a class actually needs a handle of an instance of an entire other class, or whether it could make do with an instance of a more constrained interface"). That over-coupling is what forced the visibility widening of dozens of admin setters during the original lift, which then had to be partly walked back. A constrained mutator interface removes both problems in one move: the admins keep their setters package-private, the updater can only reach into the surface area it declares, and the parent/child dedup that follows operates against a single typed seam rather than two concrete admin classes whose APIs happen to overlap.

Method Summary

Modifier and Type	Method	Description
static void	applyOnChild(VeniceHelixAdmin admin, String clusterName, String storeName, UpdateStoreQueryParams params)	Child-side update-store: mutates the store metadata in this region.
static void	applyOnParent(VeniceParentHelixAdmin admin, String clusterName, String storeName, UpdateStoreQueryParams params)	Parent-side update-store: builds an UPDATE_STORE admin message that gets written to the admin channel for child controllers to consume.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Details

applyOnChild

public static void applyOnChild(VeniceHelixAdmin admin,
 String clusterName,
 String storeName,
 UpdateStoreQueryParams params)

Child-side update-store: mutates the store metadata in this region. Lifted from the body of VeniceHelixAdmin.updateStore; the public wrapper there still performs the checkControllerLeadershipFor call and acquires the per-store write lock.

applyOnParent

public static void applyOnParent(VeniceParentHelixAdmin admin,
 String clusterName,
 String storeName,
 UpdateStoreQueryParams params)

Parent-side update-store: builds an UPDATE_STORE admin message that gets written to the admin channel for child controllers to consume. Lifted from the body inside VeniceParentHelixAdmin.updateStore's acquireAdminMessageLock try-finally; the lock acquire/release stays in the public wrapper there.