Source code
package org.apache.kafka.streams.state.internals;
import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.common.IsolationLevel;
import org.apache.kafka.common.utils.Bytes;
import org.apache.kafka.streams.KeyValue;
import org.apache.kafka.streams.state.internals.PrefixedWindowKeySchemas.TimeFirstWindowKeySchema;
import org.rocksdb.WriteBatch;
import java.util.Collection;
import java.util.Map;
import java.util.Optional;
/**
* A RocksDB backed time-ordered segmented bytes store for window key schema.
*/
public class RocksDBTimeOrderedKeyValueBytesStore extends AbstractRocksDBTimeOrderedSegmentedBytesStore<KeyValueSegment> {
RocksDBTimeOrderedKeyValueBytesStore(final String name,
final String metricsScope) {
super(name,
Long.MAX_VALUE,
new TimeFirstWindowKeySchema(),
Optional.empty(),
new KeyValueSegments(name, metricsScope, Long.MAX_VALUE, Long.MAX_VALUE));
}
@Override
protected KeyValue<Bytes, byte[]> getIndexKeyValue(final Bytes baseKey, final byte[] baseValue) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
@Override
Map<KeyValueSegment, WriteBatch> getWriteBatches(final Collection<ConsumerRecord<byte[], byte[]>> records) {
return getWriteBatches(
records,
WindowKeySchema::extractStoreTimestamp,
null, // never an indexed store -- not needed
TimeFirstWindowKeySchema::fromNonPrefixWindowKey
);
}
@Override
protected IndexToBaseStoreIterator getIndexToBaseStoreIterator(final SegmentIterator<KeyValueSegment> segmentIterator,
final IsolationLevel isolationLevel) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
}
Run 1
The code is generally readable with clear class naming and logical organization. The structure is straightforward and follows a clean hierarchy. Nesting is minimal and the action granularity is appropriate, with one main action per line. The use of descriptive method names and comments helps clarify intent, though some method signatures are dense. The constructor parameters are well-aligned but could benefit from explanatory comments. Unsupported methods are clearly marked with exceptions. Overall, it's maintainable code with only minor readability improvements needed around parameter clarity and documentation.
Run 2
The code is well-structured and follows clean code principles. The class extends an abstract base class, with constructor injection clearly showing dependencies. Methods are short and focused, with one action per line. The use of UnsupportedOperationException with clear messages indicates the methods are intentionally not implemented for this store type. The delegate method getWriteBatches is concise and readable, using method references for clarity. Nested structures are minimal, and the code reads naturally from constructor to method implementations. The comment on the null parameter adds helpful context. Overall, this is a clear, concise implementation with strong intent.
Run 3
This code has good structure (clear class hierarchy, logical methods) but suffers from several readability issues. The constructor call is deeply nested with 4+ parameters, making it hard to parse intent. Method naming like `getIndexKeyValue` and `getIndexToBaseStoreIterator` adds confusion since they throw `UnsupportedOperationException`, suggesting unclear abstraction boundaries. The use of `Optional.empty()` and `null` parameters (with ambiguous comments) creates uncertainty about state management. Long method signatures (`getWriteBatches` with `Collection<ConsumerRecord<byte[], byte[]>>`) reduce readability. While the code is concise and flat (no deep nesting in logic), the density of type parameters and unclear purpose of some abstractions (like `Long.MAX_VALUE` parameters) creates cognitive overhead. The lack of clarifying comments for non-obvious design decisions (except one brief inline comment) also hinders understanding.
Run 1
Code Structure: The class is logically organized into a constructor and focused overrides, although unsupported inherited operations add some noise. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: Descriptive names, the class comment, and method references communicate the store's purpose, but repeated Long.MAX_VALUE arguments and a null parameter require superclass knowledge. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs one clear action, and multiline calls separate arguments cleanly. Reading flow: The constructor followed by overrides provides a natural progression; lengthy signatures, uneven alignment, and tightly grouped imports slightly reduce visual readability.
Run 2
Code Structure: The class is logically organized into a constructor and focused overrides, with no tangled logic. Nesting: Methods are flat and contain no nested control flow. Clarity of intent: Descriptive class and method names, the class documentation, and the comment explaining the null argument communicate purpose well. However, positional Long.MAX_VALUE arguments and unsupported inherited operations require superclass knowledge. Code length: The implementation is concise with little unnecessary code. Action granularity: Each method performs one clear action; multiline calls keep arguments readable. Reading flow: The progression from initialization to overrides is natural, though inconsistent continuation indentation and limited import spacing slightly reduce polish.
Run 3
Code Structure: Logically organized as a small subclass with a constructor and focused overrides; imports could be grouped more consistently. Nesting: Very flat, with no nested control flow. Clarity of intent: Descriptive class and method names, a class comment, and an explanation of the null argument clarify its purpose. However, repeated Long.MAX_VALUE values and unsupported overrides require superclass knowledge to fully understand. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action, and multiline calls keep arguments separate. Reading flow: Natural progression from construction to overridden behavior, though uneven parameter indentation and long signatures slightly disrupt scanning.