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 clear class hierarchy and minimal nesting. The class name and Javadoc effectively communicate its purpose. Constructor parameters are logically organized. Exception messages are concise and unambiguous. Method names and references to functional interfaces (WindowKeySchema::extractStoreTimestamp) enhance clarity. Slight verbosity exists in constructor parameter alignment and the presence of methods that only throw exceptions, which could be abstracted or documented better. Overall, the code is highly readable, maintainable, and follows clean code principles.
Run 3
The code is generally readable with good structure, clear class purpose stated in the Javadoc, and concise method overrides. However, it suffers from several issues: unnecessary imports (Bytes, IsolationLevel), deeply chained constructor arguments, and inconsistent indentation in method calls. The UnsupportedOperationException messages are clear but the overall action granularity is mixed. The use of super with 5 arguments reduces readability and could be improved with a builder pattern. While the code is logically organized, the high nesting of arguments and inconsistent formatting detract from clarity.
Run 1
Code Structure: A small, logically organized class separates initialization, batch writing, and unsupported operations. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names, explicit exceptions, and the comment explaining the absent index clarify behavior; repeated Long.MAX_VALUE arguments and the window-schema terminology in a key-value store require contextual knowledge. Code length: Concise, with little unnecessary code beyond required overrides. Action granularity: Each statement performs a single clear action, and multiline calls make arguments easy to scan. Reading flow: The constructor followed by overrides is natural, though inconsistent continuation indentation and imports without grouping slightly reduce readability.
Run 2
Code Structure: Clearly organized into a constructor and focused overrides, with straightforward inheritance-based delegation. Nesting: Flat throughout, with no nested control flow. Clarity of intent: Descriptive class and method names, a brief class comment, and an explanation for the null argument clarify purpose; repeated Long.MAX_VALUE arguments and unsupported inherited operations require some framework knowledge. Code length: Concise, with little unnecessary code, although exception messages are duplicated. Action granularity: Each statement performs a single clear action, and multiline calls make arguments easy to distinguish. Reading flow: Natural progression from initialization to overridden behavior; slightly inconsistent indentation and tightly grouped package/import declarations modestly reduce polish.
Run 3
Code Structure: A small, logically organized class with a constructor and focused overrides. Nesting: Flat control flow with no nested conditionals or loops. Clarity of intent: Descriptive class and method names, a class comment, and an explanation of the null argument make the purpose clear; inherited behavior, positional Long.MAX_VALUE arguments, and unsupported overrides require some external context. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action, and multiline calls separate arguments cleanly. Reading flow: Methods follow a natural order and consistent formatting, though uneven parameter alignment and imports without grouping slightly reduce polish.