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
SchemaResult
in IPC deviates from other implementations
#2445
Comments
@skejserjensen thank you for the great ticket and writeup ❤️ @avantgardnerio or @liukun4515 this might be relevant to you -- is there any chance one of you has some time to fix this issue? |
SchemaResult
deviates from other implementationsSchemaResult
in IPC deviates from other implementations
pick up this. But it maybe take look later this week. |
From the
Ipc message has the implementation with
converting the schema to other type has the different implementation. |
@alamb I think @skejserjensen use the an error method to decode or deserialize the bytes from rust The flight or ipc message for the schema may contains the |
The input of api https://github.com/apache/arrow/blob/072ae55dc8172bb1a898fda5d5a83ec063b05a6d/go/arrow/flight/record_batch_reader.go#L135 of go |
The api you called in the rust and go are not the same. But in the rust |
This is caused by different implementation for in sides, and we can get the detail reason from this apache/arrow#13853 (comment) |
@skejserjensen , you can implement You can follow bellow code which is in the arrow-rs.
|
The define of
In the server side, you can wrap any data as the bytes as the schema, but in the client side you should use the corresponding decoder to decode the data. If you want to use the utils or api in c++/go side, you should wrap the data as the format which should be adapted to the client api. @skejserjensen I think it is not a bug or issue, just a problem about how to implement the server api and how to use the client api. |
You can change your server code to
|
@liukun4515 That seems out of date, the current definition in /*
* Wrap the result of a getSchema call
*/
message SchemaResult {
// The schema of the dataset in its IPC form:
// 4 bytes - an optional IPC_CONTINUATION_TOKEN prefix
// 4 bytes - the byte length of the payload
// a flatbuffer Message whose header is the Schema
bytes schema = 1;
} Defining that it should be the IPC message |
Thanks @zeroshade In the rust side, the definition is
@alamb Maybe we should update the |
@zeroshade I will try to fix this in the rust side, but it will be released in the next version about 22.0.0 or later. You can fix it in your side temporarily |
@liukun4515 and @zeroshade thank you for looking into this issue. Based on @liukun4515's previous comment, I have also been looking into encoding |
I create an issue to fix the bug. #2571 |
Automatically added labels {'arrow'} from #2586 |
Automatically added labels {'api-change'} from #2586 |
api change label was automatically added by script accidentally. api change should only be on the PRs that introduced the changes |
Describe the bug
The
SchemaResult
produced bySchemaAsIpc
can be converted to aSchema
by the Rust implementation of Apache Arrow Flight but not other implementations of Apache Arrow Flight (tested the Go, Java, and Python implementations).To Reproduce
For the Rust server, implement
FlightService.get_schema()
as:Attempt to retrieve and print the
Schema
using the following Rust code:Attempt to retrieve and print the
Schema
using the following Python code:Expected behavior
The Rust code should successfully retrieve and print the
Schema
while the Python code should fail due to the followingOSError
being raised:Additional context
As the issue was first discovered using a client written in Go, we first raised apache/arrow#13853 as we believed the problem was in the Go implementation of Apache Arrow Flight. But from the comments provided by @zeroshade on that issue, it seems that the Rust implementation of Apache Arrow Flight deviates from the other implementations in how a
Schema
is serialized. For example, both the C++ and Go implementations include the continuation indicator (0xFFFFFFFF) followed by the message length as a 32-bit integer before theSchema
:16 0 0 0 0 0 10 0 14 0 12 0 11 0 4 0 10 0 0 0 20 0 0 0 0 0 0 1 4 0 10 0 12 0 0 0 8 0 4 0 10 0 0 0 8 0 0 0 8 0 0 0 0 0 0 0 3 0 0 0 136 0 0 0 52 0 0 0 4 0 0 0 148 255 255 255 16 0 0 0 20 0 0 0 0 0 0 3 16 0 0 0 206 255 255 255 0 0 1 0 0 0 0 0 5 0 0 0 118 97 108 117 101 0 0 0 192 255 255 255 28 0 0 0 12 0 0 0 0 0 0 10 32 0 0 0 0 0 0 0 0 0 6 0 8 0 6 0 6 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 9 0 0 0 116 105 109 101 115 116 97 109 112 0 0 0 16 0 20 0 16 0 0 0 15 0 4 0 0 0 8 0 16 0 0 0 24 0 0 0 32 0 0 0 0 0 0 2 28 0 0 0 8 0 12 0 4 0 11 0 8 0 0 0 32 0 0 0 0 0 0 1 0 0 0 0 3 0 0 0 116 105 100 0
255 255 255 255 224 0 0 0 16 0 0 0 0 0 10 0 12 0 6 0 5 0 8 0 10 0 0 0 0 1 4 0 12 0 0 0 8 0 8 0 0 0 4 0 8 0 0 0 4 0 0 0 3 0 0 0 124 0 0 0 52 0 0 0 4 0 0 0 160 255 255 255 0 0 1 3 16 0 0 0 24 0 0 0 4 0 0 0 0 0 0 0 5 0 0 0 118 97 108 117 101 0 0 0 210 255 255 255 0 0 1 0 204 255 255 255 0 0 1 10 16 0 0 0 32 0 0 0 4 0 0 0 0 0 0 0 9 0 0 0 116 105 109 101 115 116 97 109 112 0 6 0 8 0 6 0 6 0 0 0 0 0 1 0 16 0 20 0 8 0 6 0 7 0 12 0 0 0 16 0 16 0 0 0 0 0 1 2 16 0 0 0 28 0 0 0 4 0 0 0 0 0 0 0 3 0 0 0 116 105 100 0 8 0 12 0 8 0 7 0 8 0 0 0 0 0 0 1 32 0 0 0
255 255 255 255 248 0 0 0 16 0 0 0 0 0 10 0 12 0 10 0 9 0 4 0 10 0 0 0 16 0 0 0 0 1 4 0 8 0 8 0 0 0 4 0 8 0 0 0 4 0 0 0 3 0 0 0 148 0 0 0 60 0 0 0 4 0 0 0 136 255 255 255 16 0 0 0 24 0 0 0 0 0 0 3 24 0 0 0 0 0 0 0 0 0 6 0 8 0 6 0 6 0 0 0 0 0 1 0 5 0 0 0 118 97 108 117 101 0 0 0 188 255 255 255 16 0 0 0 24 0 0 0 0 0 0 10 36 0 0 0 0 0 0 0 8 0 12 0 10 0 4 0 8 0 0 0 8 0 0 0 0 0 1 0 3 0 0 0 85 84 67 0 9 0 0 0 116 105 109 101 115 116 97 109 112 0 0 0 16 0 20 0 16 0 0 0 15 0 8 0 0 0 4 0 16 0 0 0 16 0 0 0 24 0 0 0 0 0 0 2 28 0 0 0 0 0 0 0 8 0 12 0 8 0 7 0 8 0 0 0 0 0 0 1 32 0 0 0 3 0 0 0 116 105 100 0 255 255 255 255 0 0 0 0
The text was updated successfully, but these errors were encountered: