Skip to content

KAFKA-20132: Implement TimestampedKeyValueStoreWithHeaders (4/N)#21454

Open
aliehsaeedii wants to merge 5 commits intoapache:trunkfrom
aliehsaeedii:changelogging
Open

KAFKA-20132: Implement TimestampedKeyValueStoreWithHeaders (4/N)#21454
aliehsaeedii wants to merge 5 commits intoapache:trunkfrom
aliehsaeedii:changelogging

Conversation

@aliehsaeedii
Copy link
Contributor

@aliehsaeedii aliehsaeedii commented Feb 11, 2026

This PR implements the changelogging layer of the
TimestampedKeyValueStoreWithHeaders introduced in KIP-1271.

Reviewers: TengYao Chi frankvicky@apache.org, Matthias J. Sax
matthias@confluent.io

Copy link
Contributor

@frankvicky frankvicky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM

assertEquals(hi, collector.collected().get(0).key());
assertArrayEquals(there.value(), (byte[]) collector.collected().get(0).value());
assertEquals(97L, collector.collected().get(0).timestamp());
Headers headers0 = collector.collected().get(0).headers();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

assertEquals(hi, collector.collected().get(0).key());
assertArrayEquals(there.value(), (byte[]) collector.collected().get(0).value());
assertEquals(97L, collector.collected().get(0).timestamp());
Headers headers0 = collector.collected().get(0).headers();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

assertEquals(hello, collector.collected().get(1).key());
assertArrayEquals(world.value(), (byte[]) collector.collected().get(1).value());
assertEquals(98L, collector.collected().get(1).timestamp());
Headers headers1 = collector.collected().get(1).headers();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

assertArrayEquals(there.value(), (byte[]) collector.collected().get(0).value());
assertEquals(97L, collector.collected().get(0).timestamp());

Headers headers = collector.collected().get(0).headers();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

assertEquals(hi, collector.collected().get(0).key());
assertArrayEquals(there.value(), (byte[]) collector.collected().get(0).value());
assertEquals(97L, collector.collected().get(0).timestamp());
Headers headers0 = collector.collected().get(0).headers();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

final

@mjsax mjsax added kip Requires or implements a KIP ci-approved and removed triage PRs from the community labels Feb 12, 2026
/**
* Extract raw value from serialized ValueTimestampHeaders.
*/
static byte[] rawValue(final byte[] rawValueTimestampHeaders) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have static <T> T value(...) above -- given that we need rawValue here, wondering if value(...) from above is actually needed or not at all?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that method returns the deserialized value while raawValue returns a byte[]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I am not questioning that we add rawValue in this PR, I am asking why did we add value(...) in a previous PR, and when would we use it?

But it's somewhat unrelated to this PR, and it's only internal code here. So we could remove value(...) if unused also at some point in the future. Was just wondering.

}
}

void log(final Bytes key, final byte[] value, final long timestamp, final Headers headers) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we just extend InternalProcessorContext.log(...) with a new Headers parameter and not add a new overload, and update all existing code accordingly, I believe we can remove the method and reuse the existing one from ChangeLoggingKeyValueBytesStore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a very big change. It will chnage many tests.

@Test
public void shouldHandleNullValueInPut() {
final InternalMockProcessorContext<String, Long> context = mockContext();
context.setTime(42L);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would we also need to set a header, and use the context header when writing into the changelog?

@Test
public void shouldHandleNullValueInPutIfAbsent() {
final InternalMockProcessorContext<String, Long> context = mockContext();
context.setTime(50L);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As above

/**
* Extract raw value from serialized ValueTimestampHeaders.
*/
static byte[] rawValue(final byte[] rawValueTimestampHeaders) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I am not questioning that we add rawValue in this PR, I am asking why did we add value(...) in a previous PR, and when would we use it?

But it's somewhat unrelated to this PR, and it's only internal code here. So we could remove value(...) if unused also at some point in the future. Was just wondering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci-approved kip Requires or implements a KIP streams

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants