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 well-structured and highly readable. It follows a clear logical organization with a focused class that extends a base class and overrides specific methods. Nesting is minimal, with only a single level of indentation within method bodies. Intent is clearly communicated through the class name, method names, and descriptive comments. The code is concise without being overly verbose, avoiding unnecessary boilerplate. Action granularity is appropriate, with each method performing a single logical operation. Reading flow is natural, presenting the constructor first followed by overridden methods in a logical order. The use of meaningful parameter names and proper formatting enhances readability. Minor deductions could be made for the slightly long constructor call spanning multiple lines and the unsupported operation exceptions, but these are appropriate for the implementation context.
Run 2
The code is well-structured with a clear class hierarchy and sensible method organization. Imports are clean and the class has a clear purpose. However, several issues reduce readability: the constructor uses the numeric value Long.MAX_VALUE repeatedly without explanation (magic numbers), and the null parameter in getWriteBatches lacks clear intent despite the comment. Some method calls span multiple lines with indentation that disrupts reading flow. The code is concise, which is good, but the brevity comes at the cost of explanatory documentation. Nested elements are minimal, which is positive. Overall, the code is understandable but relies on the reader knowing the framework internals and window key schema behavior.
Run 3
The code is well-structured with a clear class hierarchy and single responsibility. Methods are concise and have descriptive names. Nesting is minimal, only one level in the constructor call. The intent is explicit through method names like 'getWriteBatches' and 'getIndexKeyValue'. Comments and exception messages clearly state unsupported operations. The code is economical, keeping methods short and focused. One action per line is maintained, and the flow reads naturally from class declaration to constructor to overridden methods. Minor deductions for using 'null' as a parameter (requiring a comment) and slightly compact indentation in the constructor, but overall readability is high.
Run 1
Code Structure: Clearly organized as a small subclass with a constructor and focused overrides. Nesting: No nested control flow, making the code easy to scan. Clarity of intent: Descriptive method names, explicit unsupported-operation exceptions, and the comment explaining the null argument convey purpose well; repeated Long.MAX_VALUE arguments and reliance on inherited behavior require some external context. Code length: Concise, with minimal boilerplate and no unnecessary logic. Action granularity: Each method performs one clear action, and multiline arguments remain readable. Reading flow: The constructor followed by overrides provides a natural progression, though uneven parameter alignment, ungrouped imports, and the window-schema terminology in a key-value store slightly reduce clarity.
Run 2
Code Structure: The class is logically organized into a constructor and small overridden methods. Nesting: There are no nested control-flow blocks, making it easy to scan. Clarity of intent: Descriptive class and method names, the class documentation, and the indexing comment communicate purpose; however, repeated Long.MAX_VALUE arguments and unsupported inherited operations require superclass knowledge. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs a single clear action, and multiline calls separate arguments cleanly. Reading flow: The constructor-to-overrides sequence is natural, though inconsistent parameter alignment and tightly grouped imports slightly reduce visual polish.
Run 3
Code Structure: A logically organized class with a constructor and focused overrides; inheritance delegates implementation details cleanly. Nesting: No nested control flow, making methods easy to scan. Clarity of intent: Descriptive names, a class comment, and an inline explanation clarify behavior, although Long.MAX_VALUE arguments and the null parameter require superclass knowledge. Code length: Concise, with little unnecessary code; repeated exception messages are minor duplication. Action granularity: Each statement performs a single action, and multiline calls separate arguments clearly. Reading flow: Natural progression from initialization to overridden operations, slightly weakened by inconsistent continuation indentation and tightly grouped imports.