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) {
{
int firstScore = 72;
int secondScore = 85;
int higherScore;
if (firstScore > secondScore) {
higherScore = firstScore;
} else {
higherScore = secondScore;
}
}
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 contains a stray, unrelated block of Java code (comparing integers) embedded inside the getIndexKeyValue method before the exception throw, which completely breaks logical structure and clarity. This block appears to be an accidental paste and makes the code ambiguous and confusing. Nesting is otherwise shallow, but the presence of this dead code destroys reading flow and makes the intent unclear. The class structure itself is straightforward, and method signatures are readable, but the unrelated block dominates the readability assessment. Action granularity is acceptable in most methods. Code length is reasonable for the class but contaminated by extraneous content. Overall, the accidental inclusion of unrelated logic severely undermines readability despite otherwise clean structure and naming.
Run 2
The code has serious readability problems. First, there's an unrelated block of Java code (comparing two integers and assigning higherScore) inexplicably placed inside the getIndexKeyValue method before the throw statement — this is confusing and suggests a copy-paste error. The class structure itself is logical, with clear inheritance and constructor parameters, but method implementations are scattered. Nesting is relatively flat, which is positive. However, clarity of intent suffers because getIndexKeyValue has dead code and an unclear purpose. Action granularity is acceptable in most methods, with one action per line, but the formatting is inconsistent, especially in the getWriteBatches call with inline comments. The reading flow is disrupted by the misplaced code block. Code length is reasonable but inflated by unnecessary elements. Overall, the code appears broken or incomplete, which severely impacts readability and maintainability.
Run 3
The code is poorly structured and contains an unrelated block of Java code (comparing two integers) inserted in the middle of the `getIndexKeyValue` method, which severely disrupts readability and logical flow. The class itself is relatively short and the methods are mostly one-liners, but the abrupt insertion of irrelevant code creates major confusion about intent. Nesting is minimal, but the reading flow is broken by the misplaced snippet. Action granularity is acceptable elsewhere, but the overall clarity is undermined by the presence of dead code and the unsupported operations. The constructor is reasonably clear, but the class lacks cohesion due to the inexplicable nested logic. The code length is concise, but that cannot compensate for the glaring structural flaw.
Run 1
Code Structure: The class is organized into a constructor and focused overrides, but an unrelated score-comparison block disrupts getIndexKeyValue. Nesting: Most methods are flat; the extraneous block adds unnecessary scope and conditional nesting. Clarity of intent: Descriptive names, superclass delegation, and explicit unsupported-operation exceptions clarify the store's purpose, while unused score variables introduce confusion. Code length: Generally concise, but the score-comparison block adds unnecessary lines without contributing to functionality. Action granularity: Statements mostly perform one action per line, making individual operations easy to follow. Reading flow: Method ordering and delegation are natural, but inconsistent indentation, the stray block, tightly grouped imports, and uneven parameter alignment interrupt scanning.
Run 2
Code Structure: The class and overrides are logically organized, but an unrelated score-comparison block disrupts cohesion. Nesting: Most methods are flat; the redundant block and its if/else add unnecessary nesting. Clarity of intent: Descriptive names, the class comment, and explicit unsupported-operation exceptions clarify the store's purpose, but unused score variables are confusing. Code length: Generally concise, though the irrelevant comparison adds avoidable lines. Action granularity: Statements mostly perform one action per line, making individual operations easy to follow. Reading flow: Delegation and method ordering are natural, but inconsistent indentation, the stray block, and uneven parameter alignment interrupt readability.
Run 3
Code Structure: The class is logically organized around a constructor and overridden methods, but an unrelated score-comparison block disrupts cohesion. Nesting: Mostly flat, with an unnecessary nested block and a simple if/else. Clarity of intent: Descriptive names, the class comment, and explicit unsupported-operation exceptions convey the store's role, while unused score variables obscure getIndexKeyValue's purpose. Code length: Generally concise, but the irrelevant comparison adds needless lines. Action granularity: Statements mostly perform one action per line, and multiline calls separate arguments clearly. Reading flow: Method organization is natural, but inconsistent indentation, uneven parameter alignment, and the stray block interrupt readability.