-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MINOR: cleanup KStream JavaDocs (7/N) - repartition/to/toTable #18760
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I left some comments
* The topic names for each record to send to is dynamically determined based on the {@link TopicNameExtractor}. | ||
* Materialize the record of this stream to different topics. | ||
* The provided {@link TopicNameExtractor} is applied to each input record to compute the output topic name. | ||
* All topics should be manually created before they are use (i.e., before the Kafka Streams application is started). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* All topics should be manually created before they are use (i.e., before the Kafka Streams application is started). | |
* All topics should be manually created before they are used (i.e., before the Kafka Streams application is started). |
* | ||
* @param topicExtractor the extractor to determine the name of the Kafka topic to write to for each record | ||
* @param produced the options to use when producing to the topic | ||
* See {@link #to(TopicNameExtractor)}. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The parameter produced
is not explained anywhere now. Same for the other methods. Would it make sense to refer from most generic to the most specific overload instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's covered above on to(String)
as well as to(TopicNameExtractor)
:
<p>To explicitly set key/value serdes or the partitioning strategy, use {@link #to(String, Produced)}.
Not sufficient, or did you miss it?
Would it make sense to refer from most generic to the most specific overload instead?
I did consider this originally, but found if overall more complicated than helpful, and though it's easier to describe the most simple overload and just add "forward reference" (as quoted above, and used elsewhere) instead.
* by Kafka Streams. | ||
* | ||
* <p>Note: If the result {@link KTable} is materialized, it is not possible to apply | ||
* {@link StreamsConfig#REUSE_KTABLE_SOURCE_TOPICS "source topic optimization"}, because |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of this syntax. Do you know / have you checked that it works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not intent to make it syntax, but just regular text with a link... If that's confusing, happy to change it.
283be2d
to
2142d88
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thanks!
This PR is great and has given me an idea for improving our CI process. This PR introduce a java doc error, and hence QA does not run
By contrast, https://github.com/apache/kafka/blob/trunk/build.gradle#L710 Although #18838 resolves the current doc error, I believe we should enhance our CI to prevent similar issues from occurring in the future. To be honest, it is too hard to request reviewers to check all contents of CI. Maybe we can add |
Thanks for highlighting this issue (and thanks for the PR to fix it). The build for this PR did not surface this issue (otherwise we would not have merged it). I agree, that it might be good to fail PR builds if there is JavaDocs errors. |
…e#18760) Reviewers: Lucas Brutschy <[email protected]>
…e#18760) Reviewers: Lucas Brutschy <[email protected]>
No description provided.