-
Notifications
You must be signed in to change notification settings - Fork 605
Clarify the role of partitioning extension in Kafka #727
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
Clarify the role of partitioning extension in Kafka #727
Conversation
|
This PR also reformat the kafka spec with |
|
@duglin It seems like travis is broken on a link of another page:
|
Yep - opened a PR to fix it. |
| topic, but the source is another transport (e.g. HTTP), and the user needs a way | ||
| to key the record. As a counter example, It doesn't make sense to use it when | ||
| the sink and source are Kafka topics, because this may cause the re-keying of | ||
| the records. |
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.
Just to make it easier to find.... ^^^ is the real change
| The 'key' of the Kafka message MAY be populated by a "Key Mapper" function, | ||
| which might map the key directly from one of the CloudEvent's attributes, but | ||
| might also use information from the application environment, from the | ||
| CloudEvent's data or other sources. |
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.
^^^ is real change
| specific. | ||
|
|
||
| Every implementation SHOULD provide a default "Key Mapper" implementation that | ||
| Every implementation SHOULD provide an opt-in "Key Mapper" implementation that |
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.
^^^ is real change
|
@clemensv I believe we're waiting for some suggested edits from you on this one, right? |
|
There is a long backlogged AI for me to review this, but -- oddly -- I have no objections. |
|
ok - I'll add this to the agenda for today. |
|
@slinkydeveloper there's a conflict - can you rebase? |
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
30915e7 to
38f5bbf
Compare
|
This was approved during the 2/25 call - providing @slinkydeveloper rebased. |
|
@duglin feel free to push the merge button! |
* Relax a bit the partitioning extension Signed-off-by: Francesco Guardiani <francescoguard@gmail.com> * Mention streaming as a use case Signed-off-by: Francesco Guardiani <francescoguard@gmail.com> * Fix spec Signed-off-by: Francesco Guardiani <francescoguard@gmail.com>
This came out after the discussions in cloudevents/sdk-java#260
The problem with partition key extension is that it must be used in the right context and it should not be a default (or opt-out) behaviour, but it should be a very precise opt-in behaviour that only users "aware of the consequences" should adopt it.
Signed-off-by: Francesco Guardiani francescoguard@gmail.com