revamp TransportRequest handlers to support Writeable #26315
Conversation
talevy
added
:Core/Infra/Core
talevy
force-pushed
the
allow-writeable-readers-as-suppliers
branch
from
638fbef to
43fd46a
Compare
rjernst
left a comment
rjernst
left a comment
There was a problem hiding this comment.
I left some comments. Looks good in general.
There was a problem hiding this comment.
I think not, because of the client usage
There was a problem hiding this comment.
Even if the transport-client request builder pattern is to be deprecated, I think it may be best for that to be done in its own context in separate PRs
There was a problem hiding this comment.
Ah sorry, I could not see all the setters in the review without expanding.
There was a problem hiding this comment.
a single, explicit empty ctor should not be necessary (that is what the default ctor is)
There was a problem hiding this comment.
explicit call to default ctor is not necessary
There was a problem hiding this comment.
I don't think we should be adding a test for each one of these. It is not part of our API (that these are returning UOE).
There was a problem hiding this comment.
OK cool. I was on the fence about it. figured I'd discuss it after the work has been done :) will happily remove
talevy
force-pushed
the
allow-writeable-readers-as-suppliers
branch
2 times, most recently
from
1fa601e to
51885b3
Compare
This PR begins the long journey to deprecating Streamable. The idea here is to add additional method signatures that support Writeable.Reader, so that the work to migrate objects TransportMessage to implement Writeable and not Streamable. One example conversion is done in this PR: SimulatePipelineRequest.
talevy
force-pushed
the
allow-writeable-readers-as-suppliers
branch
from
51885b3 to
ccf5717
Compare
|
thanks, updated with changes reflecting the review |
|
Awesome! I'm sorry I missed this yesterday. I'm excited to see the start. |
|
@talevy Is it possible to backport this to 6.x? |
|
I suppose, I guess I didn't think about it since it was a work-in-progress transitional interface. If you think I should, I'd be happy to. I can imagine one would want to leverage the writeable interface in new actions in 7.0 that need to be backported to 6.x, so these aspects of the constructor could potentially cause merging issues? Is this what you are referring to? |
|
@talevy. Yes, this actually happened to me. I was using a new API in V7 but had to use the old one for 6.x. |
Backport of PR to 6.x, excluding the changes to SimulatePipelineRequest
Backport of PR to 6.x, excluding the changes to SimulatePipelineRequest
-- This is a pre-stage for adding the reindex API to the REST high-level-client -- Follows the pattern set in #26315
-- This is a pre-stage for adding the reindex API to the REST high-level-client -- Follows the pattern set in #26315
6 participants
This PR begins the long journey to deprecating Streamable.
The idea here is to add additional method signatures that
support Writeable.Reader, so that the work to migrate objects TransportMessage to
implement Writeable and not Streamable.
One example conversion is done in this PR: SimulatePipelineRequest.