-
Notifications
You must be signed in to change notification settings - Fork 798
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
Extract record batch structure #314
Extract record batch structure #314
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 for taking the time to do this refactor!
One ask I'll have is we're about to merge #306, which is going to affect the compression part of this work. Would you be able to adapt the code to account for these changes?
Sure. I'll redo it after the merge of #306 |
@VictorDenisov we've made a couple more optimizations that we'll have to integrate here as well: |
bdeef33
to
02f9541
Compare
02f9541
to
eaba0a1
Compare
@achille-roussel I updated the PR for the latest code. |
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.
This is looking good overall 👍I just left one question inline.
recordbatch.go
Outdated
size int32 | ||
} | ||
|
||
func (r *recordBatch) init() (err error) { |
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 looks like it's never valid to use a recordBatch
without calling init
, how about making it a constructor instead?
func newRecordBatch(codec CompressionCodec, msgs []Message) *recordBatch {
...
}
One challenge is managing the error returned by compressRecordBatch
, maybe the recordBatch
type can hold the error value like we do for writeBuffer
?
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.
Yeah, I was choosing between this option and the option that I implemented. My motivation was to not duplicate the fields in the record batch and in the declaration of the method. I don't have any strong attachment to either solution. Would you prefer your variant?
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.
Since a recordBatch
value is never fully initialized without calling init
I think it would make the code harder to use wrong to have the construction contained in a single function 👍
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.
Done
Thanks for your contribution! |
@achille-roussel @stevevls Would you be willing to merge this refactoring?
As I was working on adding transaction support to batches I realized that constructing batches deep in the invocation stack is very tedious as all their parameters should be passed to V3 and V7 functions.
I extracted record batch structure and now it's constructed one level above the writeProduceRequest functions. This way if we need to add arguments to recordBatches we can do it without touching signatures of writeProduceRequest functions.