mbrobbel commented on issue #2694: URL: https://github.com/apache/arrow-adbc/issues/2694#issuecomment-2800723252
> Wouldn't that make it difficult to treat different ADBC drivers generically? Not really. It makes it easier to implement (less bounds on the reader type), and it makes it possible for users to require additional bounds on the reader type. For example, if a user requires the reader to be `SomeTrait`, we could update the trait to require that, but that means that all readers that are not send are no longer usable. Instead we want the user to express it wants a reader that is `SomeTrait` - in addition to the bounds set on the trait associated type. The compiler will tell if the actual type of the reader implements the required traits. > > [mbrobbel@7169d89](https://github.com/mbrobbel/arrow-adbc/commit/7169d8961f11b3e1ccb1eee7b8b0a61288d09dab) > > I think this is non-controversial, should we start with this? Or is it better to just figure out the whole story and make one big change? I think the choice is: - Use the `Connection` `self`-lifetime for the returned reader (https://github.com/mbrobbel/arrow-adbc/commit/7169d8961f11b3e1ccb1eee7b8b0a61288d09dab) - this would most likely be easy to adopt for all existing implementations (they most likely just need to update the return type to match the updated trait definition). - Switch to using (generic) associated types (instead of `impl Trait` return types). This would be a bigger breaking change. I prefer moving away from `impl Trait` return types. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
