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 nam,
final String metrics) {
super(nam,
Long.MAX_VALUE,
new TimeFirstWindowKeySchema(),
Optional.empty(),
new KeyValueSegments(nam, metrics, Long.MAX_VALUE, Long.MAX_VALUE));
}
@Override
protected KeyValue<Bytes, byte[]> get(final Bytes base, final byte[] base2) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
@Override
Map<KeyValueSegment, WriteBatch> get2(final Collection<ConsumerRecord<byte[], byte[]>> rec) {
return get2(
rec,
WindowKeySchema::extractStoreTimestamp,
null, // never an indexed store -- not needed
TimeFirstWindowKeySchema::fromNonPrefixWindowKey
);
}
@Override
protected IndexToBaseStoreIterator get3(final SegmentIterator<KeyValueSegment> segment,
final IsolationLevel isolation) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
}
Run 1
The code is generally well-structured with clear class hierarchy and purpose. The constructor and get2 method demonstrate good clarity and flat nesting. However, readability is hurt by poor naming (get2, get3, nam, base2), an awkwardly aligned parameter list in get3, and multiple actions on single lines in the constructor and get2 call. The get/unimplemented methods throw clear exceptions, but the naming makes the intent of get2 ambiguous. The file is concise and has natural import ordering. Overall, it's readable but would benefit significantly from descriptive method names and improved parameter formatting. The Javadoc is helpful but minimal, and the code would be clearer if the unsupported operations were named to indicate why they are not used.
Run 2
The code follows a logical structure with clear package, imports, and class hierarchy. It extends an abstract class and overrides methods with obvious purposes, which keeps intent reasonably clear. However, readability is hindered by vague method names (get, get2, get3) and unclear parameter names (nam, base, base2), which reduce clarity of intent. The nesting is flat and concise, which is positive, but the code lacks meaningful abstraction boundaries in method naming and parameter naming. The comments are sparse, and the overall flow is natural but incomplete for an external reader unfamiliar with the codebase. The class is concise and not overly long, but the method names and parameter names need improvement to make the code more self-documenting.
Run 3
The code demonstrates good structural organization with clear class hierarchy and method separation. However, readability suffers from poor naming conventions: parameters like 'nam', 'base', 'base2', and methods 'get', 'get2', 'get3' are seriously ambiguous and require deep codebase knowledge to understand their purpose. The constructor is reasonably clean but contains magic numbers (Long.MAX_VALUE repeated). Method 'get2' has acceptable flat nesting but unclear parameter purpose. The code length is concise overall, though the addition of 'final' keywords is inconsistent. Action granularity is mostly one-action-per-line. Reading flow is disrupted by unexplained method names and lack of Javadoc on non-obvious methods. The class-level documentation provides some context, but the method naming strategy significantly undermines clarity of intent.
Run 1
Code Structure: The class is logically organized into a constructor and three overrides, with clear separation of responsibilities. Nesting: There is no control-flow nesting, making the code easy to scan. Clarity of intent: The class documentation and exception messages explain its role and unsupported operations, but names such as nam, base2, get2, and get3 obscure parameter meanings and method purposes. Code length: The implementation is concise and avoids unnecessary logic. Action granularity: Each statement performs a single action; multiline constructor and method calls remain understandable. Reading flow: The constructor-to-overrides sequence is natural, but inconsistent indentation, tightly grouped imports, and unexplained Long.MAX_VALUE arguments interrupt readability. Overall, the simple structure is readable, but weak naming and formatting prevent a higher score.
Run 2
Code Structure: The class is logically organized into a constructor and short overridden methods, though import grouping and parameter alignment are inconsistent. Nesting: There is no meaningful control-flow nesting, making the code easy to scan. Clarity of intent: The class name, superclass, and documentation establish its general purpose, but names such as get2, get3, nam, base2, and rec obscure method roles and parameter meanings. The repeated exception messages explain prohibited usage without explaining why these overrides exist. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each method performs one clear action, and statements are separated cleanly. Reading flow: The sequence is straightforward, but ambiguous naming, unusual alignment, and unexplained Long.MAX_VALUE arguments interrupt understanding.
Run 3
Code Structure: The class is logically organized into a constructor and overridden methods, with clear separation of responsibilities. Nesting: There is no nested control flow, making the code easy to scan. Clarity of intent: The class documentation, superclass, and schema types provide context, but names such as get2, get3, nam, base2, and rec obscure specific purposes. Unsupported-operation messages explain restrictions without explaining their rationale. Code length: The implementation is concise and contains little unnecessary code. Action granularity: Each statement performs one main action, and multiline calls separate arguments clearly. Reading flow: The constructor-to-method progression is natural, but inconsistent indentation, tightly packed imports, and numbered method names interrupt readability.