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 concise and well-structured, with a clear class hierarchy and clean method overrides. The class name and comments clearly express intent, and each method body is minimal. However, readability is slightly reduced by unused parameters and magic values (Long.MAX_VALUE), and some method calls rely on context to understand fully. The functional method references (WindowKeySchema::extractStoreTimestamp) are clear but require domain knowledge. Overall, the code is well-organized, flat, and easy to follow, though a few details could be improved with comments or clearer naming.
Run 3
The code is well-structured and readable. It has a clear class name and purpose, with minimal nesting and concise method implementations. The use of descriptive method names like getIndexKeyValue and getWriteBatches aids clarity. Imports are organized. Unsupported operations are clearly documented with meaningful exceptions. The class has a single constructor with logical parameters. Minor drawbacks include long parameter lists in the parent class call and a method call with multiple arguments on separate lines, which slightly impacts reading flow. Overall, the code is clean, maintainable, and easy to follow.
Run 1
1. Code Structure: Well-organized class with a constructor and clearly separated overrides; imports could be grouped more consistently. 2. Nesting: Flat methods with no nested control flow make scanning easy. 3. Clarity of intent: Descriptive names, method references, and the comment explaining the null argument clarify behavior. However, Long.MAX_VALUE arguments and unsupported inherited operations require superclass context, and the window-schema documentation is slightly confusing for a key-value store. 4. Code length: Concise, with minimal boilerplate and no unnecessary logic. 5. Action granularity: Each statement performs one clear action; multiline calls keep arguments readable. 6. Reading flow: Natural progression from initialization to overridden behavior, although uneven parameter alignment and tightly packed imports slightly reduce polish.
Run 2
Code Structure: A well-organized class with a constructor and focused overrides; inheritance clearly groups store-specific behavior. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive class and method names, a class comment, and an explanation of the null argument convey purpose, though superclass knowledge is needed to understand positional constructor arguments and unsupported operations. Code length: Concise, with little unnecessary code. Action granularity: Each method performs one clear action, and multiline argument lists improve readability. Reading flow: Consistent formatting and straightforward method order support natural reading, although constructor alignment, tightly grouped imports, and repeated generic exception messages slightly reduce polish.
Run 3
Code Structure: The class is logically organized, with a constructor followed by short overrides. Nesting: There is no nested control flow, making scanning easy. Clarity of intent: Descriptive names, the class documentation, and the comment explaining the null argument communicate purpose; however, repeated Long.MAX_VALUE arguments and unsupported overrides require superclass knowledge. Code length: The implementation is concise without unnecessary logic. Action granularity: Each statement performs one clear action, and multiline calls separate arguments cleanly. Reading flow: The constructor-to-method progression is natural, though inconsistent parameter alignment and tightly grouped imports slightly reduce visual readability.