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 flag,
final String cachedConfig) {
super(flag,
Long.MAX_VALUE,
new TimeFirstWindowKeySchema(),
Optional.empty(),
new KeyValueSegments(flag, cachedConfig, Long.MAX_VALUE, Long.MAX_VALUE));
}
@Override
protected KeyValue<Bytes, byte[]> validateAddress(final Bytes message, final byte[] finalUser) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
@Override
Map<KeyValueSegment, WriteBatch> validateRequest(final Collection<ConsumerRecord<byte[], byte[]>> session) {
return validateRequest(
session,
WindowKeySchema::extractStoreTimestamp,
null, // never an indexed store -- not needed
TimeFirstWindowKeySchema::fromNonPrefixWindowKey
);
}
@Override
protected IndexToBaseStoreIterator validateBalance(final SegmentIterator<KeyValueSegment> primaryAddress,
final IsolationLevel primaryRequest) {
throw new UnsupportedOperationException("Do not use for TimeOrderedKeyValueStore");
}
}
Run 1
The code has a clear class structure with a single responsibility, flat method bodies with minimal nesting, and concise method implementations. However, readability is undermined by misleading method names like 'validateAddress', 'validateRequest', and 'validateBalance' that imply validation but actually perform core operations. Several parameters with generic or placeholder names such as 'flag', 'cachedConfig', 'session', and 'finalUser' obscure intent. The use of null with a comment is acceptable but adds complexity. The class is short and each method performs one logical action, which aids comprehension, but the disconnection between method names and their actual behavior significantly reduces clarity and trust in the code.
Run 2
The code has clear structure with logical class organization and flat method nesting. Method names like 'validateAddress' and 'validateRequest' suggest validation but actually throw UnsupportedOperationException or delegate logic, creating ambiguity about intent. The class and variable naming is generally descriptive, but parameters like 'flag' and 'cachedConfig' in the constructor are vague. Code length is reasonable with minimal duplication. Each method performs a single action, maintaining good action granularity. Reading flow is natural - the class hierarchy extends AbstractRocksDBTimeOrderedSegmentedBytesStore, and methods are ordered logically. However, the 'validateRequest' method has a six-parameter call with a null argument explained only by a comment, reducing readability slightly. The repetition of 'Long.MAX_VALUE' creates some noise. Overall, the code is moderately readable but could benefit from clearer method naming and reduced parameter complexity.
Run 3
The code is generally readable with clear class structure and logical organization. The inheritance and constructor are straightforward. However, there are several issues affecting readability. Method naming is misleading: 'validateAddress', 'validateRequest', and 'validateBalance' suggest validation but perform store-specific operations or throw exceptions. Parameters like 'flag', 'cachedConfig', 'message', 'finalUser', and 'session' have ambiguous names that don't clearly convey their purpose. The 'validateRequest' method has a multi-line call with null comments that force the reader to understand context. Action granularity is mixed - some lines contain multiple logical operations. Nesting is acceptable with only two levels. Reading flow suffers from the disconnect between method names and their actual behavior, forcing the reader to parse the implementation to understand what each method truly does.
Run 1
Code Structure: Logically organized into a constructor and three short overrides, with clear separation of responsibilities. Nesting: Very flat, with no nested control flow. Clarity of intent: The class documentation, superclass, and schema types convey the storage purpose, but names such as validateAddress, validateBalance, flag, and finalUser obscure actual behavior. Two validation-named methods simply throw unsupported-operation exceptions. Code length: Concise, with little unnecessary code. Action granularity: Each statement performs one main action; multiline calls make argument lists easier to scan. Reading flow: Generally natural, but inconsistent indentation, tightly packed imports, and misleading identifiers interrupt readability. The comment explaining the null argument is helpful.
Run 2
Code Structure: The class is logically organized into a constructor and short overrides, although 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 documentation and schema types explain the storage purpose, but names such as validateAddress, validateBalance, flag, message, and finalUser obscure actual responsibilities. Unsupported-operation messages identify the restriction without explaining why these overrides are required. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs a single clear action; multiline calls improve readability. Reading flow: Constructor-to-overrides ordering is natural, but misleading method names and uneven formatting interrupt comprehension. The comment explaining the null argument provides useful context.
Run 3
Code Structure: The class is logically organized around 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 delegation provide context, but names such as validateAddress, validateBalance, flag, and finalUser are misleading or vague. Unsupported operations are explicit, although their messages do not explain why they are unsupported. Code length: The implementation is concise, with little unnecessary code. Action granularity: Each statement performs one main action; multiline constructor arguments and delegation remain readable. Reading flow: The overall flow is straightforward, but inconsistent indentation, imports without grouping, unexplained Long.MAX_VALUE arguments, and ambiguous naming interrupt comprehension.