[
https://issues.apache.org/jira/browse/KAFKA-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818991#comment-17818991
]
Omnia Ibrahim commented on KAFKA-16212:
---------------------------------------
I don't believe ReplicaManager have significant meaning for topic Id zero or
null. The code related to KRAFT it assume there will always be a topic Id,
while other codes that doesn't care about topic Id and interact with
ReplicaManager either not updated yet or doesn't have topic Id awareness
design. So theoretically this will simplify proposal #1.
However we will have to
1. have validation in varies places to handle topic Id as dummy values.
2. we might need to revert these dummy value and some of the validations later
in the future.
I think if we have been using similar approach in other places then proposal#1
should be fine.
With all of that said I have one worry regarding the code readability and
maintenance as having topic Id as Option/Optional.empty/Null/Zero UUID as dummy
values in the APIs in different places might be a bit confusing during
extending the code. Is there an agreement as part of KIP-516 for how long this
transition state will last before having topic id in most places and how would
this look like that I need to be aware off during extending ReplicaManager
cache to be topicId aware?
> Cache partitions by TopicIdPartition instead of TopicPartition
> --------------------------------------------------------------
>
> Key: KAFKA-16212
> URL: https://issues.apache.org/jira/browse/KAFKA-16212
> Project: Kafka
> Issue Type: Improvement
> Affects Versions: 3.7.0
> Reporter: Gaurav Narula
> Assignee: Omnia Ibrahim
> Priority: Major
>
> From the discussion in [PR
> 15263|https://github.com/apache/kafka/pull/15263#discussion_r1471075201], it
> would be better to cache {{allPartitions}} by {{TopicIdPartition}} instead of
> {{TopicPartition}} to avoid ambiguity.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
