Le 25/08/2022 à 18:19, David Li a écrit :
Hmm, what is a driver manager exactly? Does it actually manage drivers
(how so)? Is it more of a core library?
It implements the ADBC API, but dynamically delegates to an actual
implementation underneath, so that you do not have to directly link to the
driver, or to help deal with using multiple drivers within one application.
(It's analogous to the equivalents in JDBC/ODBC.)
Ok, so just to make sure I understand correctly, it doesn't have any
notion of internal registry or automated dynamic loading through
dlopen() shenanigans? :-)
Regards
Antoine.
I think it would be used more by language bindings; a C/C++
application could just link to the one driver it needs.
For Python, it implements the bindings to the C APIs by linking against the C++
driver manager. As you noted on [1], it's probably not something people would
use directly.
[1]: https://github.com/apache/arrow-adbc/issues/53
On Thu, Aug 25, 2022, at 12:08, Antoine Pitrou wrote:
Le 25/08/2022 à 17:51, David Li a écrit :
Fair enough, thank you. I'll try to expand a bit. (Sorry for the wall of text
that follows…)
These are the components:
- Core adbc.h header
- Driver manager for C/C++
- Flight SQL-based driver
- Postgres-based driver (WIP)
- SQLite-based driver (more of a testbed for me than an actual component - I
don't think we'd actually distribute this)
- Java core interfaces
- Java driver manager
- Java JDBC-based driver
- Java Flight SQL-based driver
- Python driver manager
Hmm, what is a driver manager exactly? Does it actually manage drivers
(how so)? Is it more of a core library?
I think: adbc.h gets mirrored into the Arrow repo. The Flight SQL drivers get
moved to the main Arrow repo and distributed as part of the regular Arrow
releases.
That sounds reasonable to me.
>
So the "part of Arrow 10.0.0" aspect means having a stable interface
for adbc.h, and getting the Flight SQL drivers into the main repo.
Sounds fine as well.
Regards
Antoine.
