Ah, while I was thinking of it as useful for a fallback, I'm not specifying it that way. Better ideas for names would be appreciated.
The actual precedence has never been specified. All endpoints are equivalent, so clients may use what is "best". For instance, with Matt Topol's concurrent proposal, a GPU-enabled client may preferentially try UCX endpoints while other clients may choose to ignore them entirely (e.g. because they don't have UCX installed). In practice the ADBC/JDBC drivers just scan the list left to right and try each endpoint in turn for lack of a better heuristic. On Mon, Feb 12, 2024, at 14:28, Joel Lubinitsky wrote: > 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 >>
