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 highly readable due to its clear structure, minimal nesting, and concise implementation. The class extends a descriptive base class and overrides only the necessary methods, each with a clear purpose. Method names, such as getIndexKeyValue and getWriteBatches, communicate intent effectively. The code avoids excessive nesting and maintains one action per line in most places, especially in the constructor where each argument is placed on its own line. The unsupported operations are explicitly documented with descriptive exception messages, making the class's limitations obvious. Minor deductions include some repetitive method signatures and the fact that the logic delegates to helper methods, which requires additional context to fully understand, but overall the code is concise, well-organized, and easy to follow.
Run 3
The code has clear intent with a descriptive class name and a helpful class-level JavaDoc comment. The structure is logical, and imports are properly organized. However, the constructor's parameter indentation is inconsistent with standard Java formatting, hurting reading flow. Several method overrides are effectively stubs that throw UnsupportedOperationException, which adds length without useful functionality. The getWriteBatches method delegates to an overloaded version with a lambda method reference and null argument, which obscures the purpose and makes intent less clear. Action granularity is generally reasonable, but the null parameter without an explanatory comment is ambiguous. Overall the code is readable but suffers from formatting inconsistencies and unclear delegation.
Run 1
Code Structure: Well-organized class with a constructor and focused overrides; inheritance keeps implementation details out of this class. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names, annotations, and the comment explaining the null argument make behavior understandable. However, positional constructor arguments, repeated Long.MAX_VALUE values, and unsupported overrides require knowledge of the parent abstraction. Code length: Concise, with little unnecessary code beyond required overrides. Action granularity: Each statement performs one clear action; multiline method calls make arguments easy to distinguish. Reading flow: Natural progression from initialization to overridden behavior, though inconsistent parameter alignment and imports without grouping slightly reduce visual polish.
Run 2
Code Structure: Well-organized class with a constructor and clearly separated overrides; minor import-grouping and alignment inconsistencies reduce polish. Nesting: Flat methods with no nested control flow make scanning easy. Clarity of intent: Descriptive class and method names, a class comment, and the explanation for the null argument communicate purpose, though constructor constants and unsupported inherited operations require superclass context. Code length: Concise, with little unnecessary code beyond required overrides. Action granularity: Each method performs one clear operation, and multiline arguments remain easy to distinguish. Reading flow: Natural progression from initialization to overridden behavior, with consistent spacing between methods; the long inheritance declaration and uneven parameter alignment slightly interrupt readability.
Run 3
Code Structure: A small, logically organized class with a constructor followed by focused overrides. Nesting: Entirely flat, with no conditionals or loops. Clarity of intent: Descriptive class and method names, typed parameters, and the comment explaining the null argument clarify behavior; however, repeated Long.MAX_VALUE arguments and unsupported inherited methods require superclass knowledge. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one clear action, and multiline calls separate arguments cleanly. Reading flow: Natural and easy to scan, though inconsistent continuation indentation and minimal separation between the package declaration and imports slightly reduce polish.