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 and readable. It has a clear class-level Javadoc explaining its purpose, flat structure with no nested blocks, and concise methods with single responsibilities. Method names clearly express intent, and even unsupported operations are explicitly documented with meaningful exceptions. The use of descriptive parameter names and limited method parameters maintains readability. The code is compact without sacrificing clarity, demonstrating good action granularity and natural reading flow. Minor deductions stem from static method references that require domain knowledge and the absence of deeper method-level documentation for non-obvious logic.
Run 3
The code is well-structured with clear class hierarchy and consistent method organization. Imports are grouped logically, and the single-line class Javadoc is concise. Nesting is minimal with no deep conditional blocks. Method names clearly communicate intent (e.g., getWriteBatches, getIndexKeyValue), and the UnsupportedOperationException messages explicitly state the constraint. The getWriteBatches method delegates to an overload with clear argument comments, maintaining one primary action per line in the constructor call. However, minor readability reductions include the slightly long import list and the constructor call spanning multiple lines with complex arguments. Overall, the code is readable with good separation of concerns, predictable structure, and no unnecessary verbosity.
Run 1
Code Structure: A small, logically organized class with a constructor and clearly separated overrides. Nesting: No nested control flow, making navigation easy. Clarity of intent: Descriptive names, method references, and an explanatory comment communicate specialization for a non-indexed time-ordered store; however, repeated Long.MAX_VALUE arguments and the null parameter require superclass knowledge. Code length: Concise, with little unnecessary code; unsupported overrides are explicit but repetitive. Action granularity: Each method performs one clear action, and multiline arguments improve readability. Reading flow: Natural top-to-bottom progression with consistent method formatting, though missing spacing after the package declaration, ungrouped imports, and slightly uneven parameter alignment reduce polish.
Run 2
Code Structure: A small, logically organized class with a constructor and focused overrides. Nesting: No nested control flow; methods are flat and easy to scan. Clarity of intent: Descriptive class and method names, a class-level comment, and an inline explanation of the null argument clarify purpose. Unsupported-operation messages explicitly identify prohibited functionality, though superclass knowledge is needed to understand the full behavior. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action; multiline calls separate arguments cleanly. Reading flow: Natural progression from initialization to overridden behavior, slightly weakened by inconsistent continuation indentation, tightly grouped imports, and unexplained Long.MAX_VALUE arguments.
Run 3
Code Structure: A small, cohesive class with clearly separated constructor and overridden methods. Nesting: Flat control flow with no nested conditionals or loops. Clarity of intent: Descriptive names, a class comment, and an explanation for the null argument make the purpose understandable; however, repeated Long.MAX_VALUE arguments and inherited behavior require external context. Code length: Concise, with little unnecessary code beyond required unsupported-operation overrides. Action granularity: Each statement performs one clear action, and multiline calls separate arguments cleanly. Reading flow: Natural progression from initialization to specialized operations, slightly weakened by inconsistent parameter indentation and tightly grouped imports.