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;
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,
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 with clear class and method organization, minimal nesting, and concise length. Methods throw explicit UnsupportedOperationExceptions, aiding clarity of intent. However, the getWriteBatches method delegates to an overloaded helper with several parameters, including a confusing null argument and method references, which slightly obscures intent. Visual alignment of parameters is inconsistent (e.g., Long.MAX_VALUE indentation), and trailing whitespace after null is a minor style issue. Overall, it is readable, but the parameter-heavy delegation and placeholder null reduce clarity somewhat.
Run 2
This code demonstrates strong readability through clear class structure and minimal nesting. The class extends a well-named abstract parent and its purpose is immediately clear from the name. Each method has a single, clear responsibility: one throws for unsupported operations, one delegates with a lambda, and one constructs an iterator. The methods are flat with no nested logic or conditional complexity. The boolean/optional parameters are placed on separate lines which improves scanability. The one weakness is a magic null parameter (passed for what appears to be a schema or extractor), which slightly obscures intent. Additionally, the unsupported operation methods lack explanatory comments on why they throw. However, the overall flow is natural—construct, delegate, then handle edge cases—and the code is concise with appropriate line length.
Run 3
The code is well-structured and readable, with clear separation of concerns through inheritance and method overrides. The constructor is clean, with logical parameter ordering. Methods are concise, each serving a single purpose. Except for the lambda reference, nesting is minimal. Names are descriptive, and unused methods throw meaningful exceptions. The getWriteBatches method uses method references to improve clarity. Minor drawbacks include unnecessary whitespace lines and a null parameter without explanation, which slightly reduces clarity. Overall, the code is maintainable and understandable within its Kafka Streams context.
Run 1
Code Structure: The class is logically organized into a constructor and short overridden methods, with delegation keeping responsibilities clear. Nesting: There is no control-flow nesting, making the code easy to scan. Clarity of intent: Descriptive class and method names and explicit unsupported-operation exceptions communicate purpose, though unexplained Long.MAX_VALUE arguments and a null argument require superclass knowledge. Code length: The implementation is concise, but excessive blank lines add visual noise. Action granularity: Each statement performs one clear action; multiline calls improve readability. Reading flow: Methods follow a natural sequence, although inconsistent continuation indentation, long signatures, and imports without grouping slightly disrupt the flow.
Run 2
Code Structure: The class is logically organized into a constructor and focused overrides, although import grouping and extra blank lines could be cleaner. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive class and method names, method references, and explicit unsupported-operation exceptions convey purpose; however, the null argument and repeated Long.MAX_VALUE values lack explanatory context. Code length: The implementation is concise and avoids unnecessary logic. Action granularity: Each method performs a single clear action, and multiline argument lists improve scanning. Reading flow: The constructor followed by overrides provides a natural progression, but inconsistent continuation indentation and unexplained configuration arguments slightly interrupt readability.
Run 3
Code Structure: The class is logically organized into a constructor and focused overrides, though excess blank lines and ungrouped imports reduce polish. Nesting: Methods are flat, with no complex branching or loops. Clarity of intent: Descriptive class and method names, method references, and explicit unsupported-operation messages convey purpose; however, repeated Long.MAX_VALUE arguments and an unexplained null require knowledge of the superclass API. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each method performs one clear action, and multiline arguments make calls easy to scan. Reading flow: The constructor-to-overrides progression is natural, but inconsistent continuation indentation and minor whitespace issues interrupt visual consistency.