It's not clear to me why (4) doesn't work. Can you speak more about the flow of requests here? Putting a ticket inside a FlightDescriptor makes me think something more complicated is going on.
Alternatively...just create your own gRPC service, and return whatever payload you need. There's no need to bend Flight to do something it wasn't designed to do, and apart from the Arrow/Protobuf/gRPC integrations in the data-carrying methods, there's no secret sauce in Flight anyways. On Thu, Mar 27, 2025, at 19:27, Rusty Conover wrote: > Hi everyone, > > I’d like to discuss the possibility of sending filtering predicates to an > Arrow Flight server. Currently, it’s unclear what the "proper" approach is > for achieving this. > > The GetFlightInfo method only accepts a FlightDescriptor without additional > parameters. If it allowed for extra parameters, this use case might be more > straightforward. > > I’ve considered four possible approaches for passing predicates and > retrieving the appropriate endpoints from the server: > > 1. > > *Include predicates in gRPC headers* when calling DoGet or DoExchange. > - > > This approach is limited by gRPC header size constraints. > 2. > > *Embed predicates within the ticket returned by the Arrow Flight server.* > - > > This requires the client to interpret the opaque binary ticket, > potentially blurring the client-server separation. > 3. > > *Use a DoAction request (e.g., "get_flight_endpoints")* to accept > filtering predicates and return the corresponding serialized endpoints. > 4. > > *Modify the FlightDescriptor to a command (CMD) type* and encode both > the original ticket and predicate information in the command field. > > I’m leaning toward approach #3 due to its flexibility and the advantage of > avoiding unnecessary schema serialization in FlightInfo when the client > only needs endpoints. > > Has anyone else encountered this challenge? If so, what solutions have > worked for you? > > Looking forward to your thoughts. > > Best, > Rusty
