Class HelixReadWriteStoreRepository

java.lang.Object
com.linkedin.venice.helix.CachedReadOnlyStoreRepository
com.linkedin.venice.helix.HelixReadWriteStoreRepository
All Implemented Interfaces:
ReadOnlyStoreRepository, ReadWriteStoreRepository, VeniceResource

public class HelixReadWriteStoreRepository extends CachedReadOnlyStoreRepository implements ReadWriteStoreRepository
Read write store repository which uses Helix as storage.

This repository does NOT listen the change of store from ZK. Because in Venice, this is the only once place to modify stores.

Persistence layout (only when perVersionZnodeEnabled is true):

  • /<cluster>/Stores/<name> holds the Store JSON. Its embedded versions list is the legacy set inherited from stores that pre-date the per-version-znode layout. The list is never appended to; it can only shrink (when the caller removes a legacy version) or have its entries mutated in place (e.g. via updateVersionStatus, which mutates the shared Avro record).
  • /<cluster>/Stores/<name>/versions/<n> holds each non-legacy Version as its own JSON znode. Every newly added version lands here; mutations to existing znode-versions are propagated by re-writing the znode on the next updateStore call.

When the flag is false, the entire Store (including its versions list) is persisted to the single store znode — the layout every Venice cluster used before this work. The read path is unconditionally smart and supports both layouts so readers can roll out ahead of writers.

Invariant (split layout only): a given version number lives in exactly one of the two layers. The write path enforces this by upserting target versions to /versions/<n> iff their number is NOT in the prior embedded list, and by deleting any stale per-version znode whose number remains embedded. There is no migration step that moves a legacy embedded version into a per-version znode.