-
Notifications
You must be signed in to change notification settings - Fork 842
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
Update flight definitions including backwards-incompatible change to GetSchema #2586
Conversation
I don't know why there are many format changes in the result of build file. I just build the |
#[derive(Clone, PartialEq, ::prost::Message)] | ||
pub struct HandshakeRequest { | ||
/// | ||
/// A defined protocol version | ||
/// A defined protocol version |
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.
Why is there a formatting change here?
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.
prost
had a bug that got fixed. I don't think this is a huge problem. tokio-rs/prost#694
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 not a huge problem, but it will introduce useless changes in the git diff for each build
Are you suggesting we don't check in the generated code? I personally agree with this, but I know that others prefer checking it in |
@@ -193,7 +193,10 @@ message Result { | |||
* Wrap the result of a getSchema call | |||
*/ | |||
message SchemaResult { | |||
// schema of the dataset as described in Schema.fbs::Schema. | |||
// The schema of the dataset in its IPC form: |
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.
Did they change the protocol without updating the message, or have we just always been doing this wrong?
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.
From the issue, I don't find the historical implementation for this RPC protocal.
Maybe this comment can provide some info for you apache/arrow#13853 (comment)
impl TryFrom<SchemaAsIpc<'_>> for SchemaResult { | ||
type Error = ArrowError; | ||
|
||
fn try_from(schema_ipc: SchemaAsIpc) -> ArrowResult<Self> { |
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 surprised we can change this without also needing to change the flight client?
In particular I would expect changes to
impl TryFrom<&SchemaResult> for Schema
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 flight client just can get the bytes array from GetSchema
RPC.
The server/client grpc can be generated automatically.
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.
But we provide logic to convert the SchemaResult
to a Schema
which will now fail??
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 better to make consistent with original implementation for me.
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.
My point is twofold:
- We clearly are missing a test as the change you have made to the protocol should be failing a test somewhere
- We need to update the logic to interpret the
SchemaResult
which does exist and following this PR will be incorrect
As an aside I do really wonder why arrow flight is using opaque byte objects, the whole point of using an API DSL is to avoid this but hey ho, this protocol is wild
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.
helps tooling and people find the generated code
I think the tooling has issues when it is generated into target/
which I think is best practice. I'd advocate for leaving it where it is, but .gitignoring
it, which should solve formatting without breaking IDEs.
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.
Will that work when published to crates.io or used via a git revision?
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.
If I understand the thread, it sounds like this has been resolved:
- use a flag to determine how to write
- check for the continuation token to differentiate between versions of the protocol and avoid a breaking change
- update the protobuf <-> native conversion code
- add a 4 round-trip tests: old -> new, new -> old, old -> old, new -> new
?
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.
Will that work when published to crates.io or used via a git revision?
I think it will work for cargo publish
but I think anyone depending on a git revision would require protoc
to be installed. I have not verified these claims though.
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.
https://doc.rust-lang.org/cargo/commands/cargo-publish.html
This command will create a distributable, compressed .crate file with the source code of the package in the current directory
If there is no idea about how to resolve the compatibility for the rust client/server, I will close this issue and keep it as it is. |
Arrow community will add IT to cover the RPC method. https://issues.apache.org/jira/browse/ARROW-17568 |
I will add the backwards compatibility tomorrow. |
What's your opinions about this? @alamb @carols10cents I just know java/go don't check in the diff about the generated file in file. |
@@ -254,10 +254,17 @@ impl From<SchemaAsIpc<'_>> for FlightData { | |||
} | |||
} | |||
|
|||
impl From<SchemaAsIpc<'_>> for SchemaResult { | |||
fn from(schema_ipc: SchemaAsIpc) -> Self { | |||
let IpcMessage(vals) = flight_schema_as_flatbuffer(schema_ipc.0, schema_ipc.1); |
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.
@tustvold
The original implementation has diff with the original implementation of java.
The version of java has the length as the prefix for this buffer, but the original rust does have the prefix length.
/**
* Write the serialized Message metadata, prefixed by the length, to the output Channel. This
* ensures that it aligns to an 8 byte boundary and will adjust the message length to include
* any padding used for alignment.
*
* @param out Output Channel
* @param messageLength Number of bytes in the message buffer, written as little Endian prefix
* @param messageBuffer Message metadata buffer to be written, this does not include any
* message body data which should be subsequently written to the Channel
* @param option IPC write options
* @return Number of bytes written
* @throws IOException on error
*/
public static int writeMessageBuffer(WriteChannel out, int messageLength, ByteBuffer messageBuffer, IpcOption option)
throws IOException {
// if write the pre-0.15.0 encapsulated IPC message format consisting of a 4-byte prefix instead of 8 byte
int prefixSize = option.write_legacy_ipc_format ? 4 : 8;
// ensure that message aligns to 8 byte padding - prefix_size bytes, then message body
if ((messageLength + prefixSize ) % 8 != 0) {
messageLength += 8 - (messageLength + prefixSize) % 8;
}
if (!option.write_legacy_ipc_format) {
out.writeIntLittleEndian(IPC_CONTINUATION_TOKEN);
}
out.writeIntLittleEndian(messageLength);
out.write(messageBuffer);
out.align();
// any bytes written are already captured by our size modification above
return messageLength + prefixSize;
}
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 think the original implementation for the rust is not right without the buffer size for the schema flatbuffer.
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 would agree the original Rust implementation is different, I'm not sure I would go so far as to say it is incorrect. There is no particular need to send the length, given the protobuf is already providing the message framing.
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.
agree, the layout of the schemaResult
is bytes array, which is flexible but easy to change.
After the discussion about the RPC
The current protocal of serialization for schemaresult is
All other languages are follow above protocal |
21a966e
to
0c72501
Compare
I think we have many thought about the In this PR, how about we just focus on the implementation of @tustvold @alamb @avantgardnerio I think it's time to review this, I have fixed the issue of the compatibility and make consistent with the implementation of java/c++/go |
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 test seems to cover it, so LGTM!
0c72501
to
137e2c1
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.
I think it is worth highlighting that the new client will be unable to communicate with old rust servers, I don't think there is a away around this but we should highlight this very clearly
let encoded_data = flight_schema_as_encoded_data(pair.0, pair.1); | ||
|
||
let mut schema = vec![]; | ||
arrow::ipc::writer::write_message(&mut schema, encoded_data, pair.1)?; |
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've double-checked this will write the continuation token 👍
@@ -254,10 +254,17 @@ impl From<SchemaAsIpc<'_>> for FlightData { | |||
} | |||
} | |||
|
|||
impl From<SchemaAsIpc<'_>> for SchemaResult { | |||
fn from(schema_ipc: SchemaAsIpc) -> Self { | |||
let IpcMessage(vals) = flight_schema_as_flatbuffer(schema_ipc.0, schema_ipc.1); |
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 would agree the original Rust implementation is different, I'm not sure I would go so far as to say it is incorrect. There is no particular need to send the length, given the protobuf is already providing the message framing.
Co-authored-by: Raphael Taylor-Davies <1781103+tustvold@users.noreply.github.com>
Co-authored-by: Raphael Taylor-Davies <1781103+tustvold@users.noreply.github.com>
I would like to propose we hold off on merging this PR until I create an arrow-flight 22.0.0 release candidate (in a few hours time) -- Then we can merge this PR for release in arrow-flight 23.0.0 and start working on potential downstream integrations (such as ballista, iox, etc) that will change. Thank you @liukun4515 and @tustvold for your work |
+1 |
@alamb If you have done the release for 22.0.0, please merge it. |
Benchmark runs are scheduled for baseline = e5b9d05 and contender = 4c1bb00. 4c1bb00 is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
Which issue does this PR close?
Closes #2571
Closes #2445
Rationale for this change
What changes are included in this PR?
Update the dir
format
from https://github.com/apache/arrow/tree/master/formatAre there any user-facing changes?