Application-defined metadata.
There is no inherent or required relationship between this and the app_metadata fields in the FlightEndpoints or resulting FlightData messages. Since this metadata is application-defined, a given application could define there to be a relationship, but there is none required by the spec.
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.
If the returned data has an ordering, an application can use "FlightInfo.ordered = true" or should return the all data in a single endpoint. Otherwise, there is no ordering defined on endpoints or the data within.
A client can read ordered data by reading data from returned endpoints, in order, from front to back.
Note that a client may ignore "FlightInfo.ordered = true". If an ordering is important for an application, an application must choose one of them:
Optional
flightThe descriptor associated with this info.
FlightEndpoints are in the same order as the data.
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
Set these to -1 if unknown.
The access coordinates for retrieval of a dataset. With a FlightInfo, a consumer is able to determine how to retrieve a dataset.
Generated
from protobuf message arrow.flight.protocol.FlightInfo