jacobmarble commented on PR #34331: URL: https://github.com/apache/arrow/pull/34331#issuecomment-1450526498
Whether the technical merits of the "direct driver" are truly meaningful, I support it for other reasons. --- > it's likely not too much maintenance overhead to maintain this implementation assuming we get it right. > If we can get this to a better spot with good testing, I'd be okay with getting this merged. But I do want to make it clear that the documentation / examples will likely still be pointing at using the ADBC implementation. IMHO, the existence of a "direct driver" is part of "getting it right". Eventually, someone will create such a driver, and it's better that it be a canonical driver live in this repository, rather than `github.com/StartCo/goflightsql`. (I'm thinking about the various Kafka golang clients. Confluent's driver depends on cgo, so it isn't as popular as the "pure Go" drivers published by Segment.io and Shopify.) Both implementations should behave the same way, as much as possible. Unit tests can help. > I my view, database/sql (think of it as "Golang Database connectivity") and ADBC are two independent standards. So if I do not worry about ADBC why am I forced to depend on it? People probably want to use the one or the other. So I do not suggest to have two implementations, I suggest to remove the ADBC wrapper and make it a wrapper around FlightSQL as this is what is done for every other database in Golang! This illustrates a concern I have about the Apache Arrow ecosystem. The relationship between these APIs (Arrow, Flight, FlightSQL, Arrow, database/sql) are not obvious from the outside. The most common FlightSQL client persona wants a basic SQL driver to access a database that someone else chose. Things like Arrow and ADBC don't matter to this persona, but things like "pure Go" and few dependencies do matter. -- 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]
