Thanks for proposing this David. I think the ability to include the Flight RPC service itself in the list of endpoints from which data can be fetched is a helpful addition.
The current choice of name for the URI (arrow-flight-fallback://) seems to imply that there is an order of precedence that should be considered in the list of URI’s. Specifically, as a developer receiving the list of locations I might assume that I should try fetching from other locations first. If those do not succeed, I may try the original service as a fallback. Are these the intended semantics? If so, is there a way to include the original service in the list of locations without the implied precedence? Thanks, Joel On Mon, Feb 12, 2024 at 11:52 James Duong <james.du...@improving.com.invalid> wrote: > This seems like a good idea, and also improves consistency with clients > that erroneously assumed that the service endpoint was always in the list > of endpoints. > > From: Antoine Pitrou <anto...@python.org> > Date: Monday, February 12, 2024 at 6:05 AM > To: dev@arrow.apache.org <dev@arrow.apache.org> > Subject: Re: [DISCUSS] Flight RPC: add 'fallback' URI scheme > > Hello, > > This looks fine to me. > > Regards > > Antoine. > > > Le 12/02/2024 à 14:46, David Li a écrit : > > Hello, > > > > I'd like to propose a slight update to Flight RPC to make Flight SQL > work better in different deployment scenarios. Comments on the doc would > be appreciated: > > > > > https://docs.google.com/document/d/1g9M9FmsZhkewlT1mLibuceQO8ugI0-fqumVAXKFjVGg/edit?usp=sharing > > > > The gist is that FlightEndpoint allows specifying either (1) a list of > concrete URIs to fetch data from or (2) no URIs, meaning to fetch from the > Flight RPC service itself; but it would be useful to combine both behaviors > (try these concrete URIs and fall back to the Flight RPC service itself) > without requiring the service to know its own public address. > > > > Best, > > David >
