-
Notifications
You must be signed in to change notification settings - Fork 4.2k
ARROW-15921: [Format][FlightRPC][C++][Java] Clarify interpretation of FlightEndpoint.locations #12636
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
ARROW-15921: [Format][FlightRPC][C++][Java] Clarify interpretation of FlightEndpoint.locations #12636
Changes from 7 commits
ac0648e
6ade353
ea7dbb8
7d213d9
d6d7044
8e0b2c6
11bdb7b
ca0a6ae
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -259,8 +259,15 @@ message FlightInfo { | |
| FlightDescriptor flight_descriptor = 2; | ||
|
|
||
| /* | ||
| * A list of endpoints associated with the flight. To consume the whole | ||
| * flight, all endpoints must be consumed. | ||
| * A list of endpoints associated with the flight. To consume the | ||
| * whole flight, all endpoints (and hence all Tickets) must be | ||
| * consumed. Endpoints can be consumed in any order. | ||
| * | ||
| * In other words, an application can use multiple endpoints to | ||
| * represent partitioned data. | ||
| * | ||
| * There is no ordering defined on endpoints. Hence, if the returned | ||
| * data has an ordering, it should be returned in a single endpoint. | ||
| */ | ||
| repeated FlightEndpoint endpoint = 3; | ||
|
|
||
|
|
@@ -280,9 +287,20 @@ message FlightEndpoint { | |
| Ticket ticket = 1; | ||
|
|
||
| /* | ||
| * A list of URIs where this ticket can be redeemed. If the list is | ||
| * empty, the expectation is that the ticket can only be redeemed on the | ||
| * current service where the ticket was generated. | ||
| * A list of URIs where this ticket can be redeemed. | ||
| * | ||
| * If the list is empty, the expectation is that the ticket can only | ||
| * be redeemed on the current service where the ticket was | ||
| * generated. | ||
| * | ||
| * If the list is not empty, the expectation is that the ticket can | ||
| * be redeemed at any of the locations, and that the data returned | ||
| * will be equivalent. In this case, the ticket may only be redeemed | ||
| * at one of the given locations, and not (necessarily) on the | ||
| * current service. | ||
| * | ||
| * In other words, an application can use multiple locations to | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. this clarification is very helpful to me |
||
| * represent redundant and/or load balanced services. | ||
| */ | ||
| repeated Location location = 2; | ||
| } | ||
|
|
@@ -298,6 +316,9 @@ message Location { | |
| /* | ||
| * An opaque identifier that the service can use to retrieve a particular | ||
| * portion of a stream. | ||
| * | ||
| * Tickets are meant to be single use. It is an error/undefined behavior | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "undefined behavior" sounds a bit scary given the baggage this term has in C/C++. Perhaps say that the behavior can be implement-dependent and that implementations are allowed to raise an error? |
||
| * to reuse a ticket. | ||
| */ | ||
| message Ticket { | ||
| bytes ticket = 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.
Perhaps also explain how someone is supposed to "redeem" a ticket (note that verb doesn't seem to exist in the RPC APIs)?