I am using flight but in a fairly specific way, so my opinion may not be useful for your case. But, I think you can use a variety of ways to handle a variety of cases: - if your predicate is simple or compact you can specify to Get/Exchange- if your predicate has a large representation or is complex you can pass it via DoAction (preferable only if you're not immediately fetching results) I personally pass substrait plans via DoAction then use DoGet, etc to move result sets around. As David said, since the only real thing to leverage from Flight are the data carrying methods and the already written framework, I essentially use custom logic everywhere else (my Tickets are protobuf messages and I don't do anything with descriptors, etc). - Aldrin Sent from Proton Mail for iOS On Thu, Mar 27, 2025 at 04:59, David Li <lidav...@apache.org> wrote: 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
signature.asc
Description: OpenPGP digital signature
