I wonder if there is a relatively simple way to solve this problem. The ADBC driver manager libraries already make it possible to dynamically load drivers, and I believe these libraries already allow the user to specify which driver to use by passing either a bare filename or a full file path.
So perhaps we could simply establish an ordered list of standard directory locations in which the ADBC driver manager will look for drivers when they are specified by bare filename. We would have to specify this differently for each mainstream type of OS, but I think that is doable. This could be codified in the ADBC docs and implemented in the ADBC driver managers. Anyone looking to achieve system-wide ADBC driver "registration" could take advantage of this, whereas anyone who prefers application-specific implementation could safely ignore it. I suspect that we would want the driver manager to look first in application-specific directories (which might vary depending on which ADBC driver language library one is using), then fall back on user-level config directories, then finally fall back on system-level config directories. I believe that Windows, macOS, and Linux distros all have standard user-level and system-level config directories that are often used for this type of thing. Does this seem reasonable? Are there any gotchas that would prevent an approach like this from working? Ian On Mon, Apr 1, 2024 at 5:44 PM Curt Hagenlocher <c...@hagenlocher.org> wrote: > The advantage to system-wide registration of drivers (however that's > accomplished) is of course that it allows driver authors to provide a > single installer or set of instructions for the driver to be installed > without regard for different usage scenarios. So if Tableau and Excel can > both use ODBC drivers, then I (as a hypothetical author of a niche driver) > don't have to solve N installation problems for N possible use cases. And > my spouse (as a non-developer finance user) can just run one installer and > know that the data source will be available in multiple tools. Or at least > that's the principle. > > For a real-world example, compare the instructions for installing ODBC > drivers into Tableau ( > > https://help.tableau.com/current/pro/desktop/en-us/examples_otherdatabases.htm > ) with those for installing JDBC drivers ( > > https://help.tableau.com/current/pro/desktop/en-us/examples_otherdatabases_jdbc.htm > ). The JDBC instructions include copying or installing files to a specific > directory which possibly needs to be created. The ODBC instructions ... > don't. > > With what I'm most immediately invested in -- database drivers for > Microsoft Power BI -- part of the problem actually ends up being that many > drivers are closed source and/or not freely redistributable. So for someone > to use Power BI with Oracle, they either need a way to install Oracle > drivers onto their machine in a standard way which lets us find them or we > need to go through a painful and sometimes expensive "biz dev" effort to > get the right to redistribute those drivers and install them ourselves. > > I am of course aware that there can also be significant downsides to such > system-wide registration. > > -Curt > > On Wed, Mar 20, 2024 at 7:23 AM Antoine Pitrou <anto...@python.org> wrote: > > > > > Also, with ADBC driver implementations currently in flux (none of them > > has reached the "stable" status in > > https://arrow.apache.org/adbc/main/driver/status.html), it might be a > > disservice to users to implicitly fetch drivers from potentially > > outdated DLLs on the current system. > > > > Regards > > > > Antoine. > > > > > > Le 20/03/2024 à 15:08, Matt Topol a écrit : > > >> it seems like the current driver manager work has been largely > targeting > > > an app-specific implementation. > > > > > > Yup, that was the intention. So far discussions of ADBC having a > > > system-wide driver registration paradigm like ODBC have mostly been to > > > discuss how much we dislike that paradigm and would prefer ADBC to stay > > > with the app-specific approach that we currently have. :) > > > > > > As of yet, no one has requested such a paradigm so the discussions > > haven't > > > gotten revived. > > > > > > On Wed, Mar 20, 2024 at 9:22 AM David Coe <david....@microsoft.com > > .invalid> > > > wrote: > > > > > >> ODBC has different OS-level driver managers available on their > > respective > > >> systems. It seems like the current driver manager< > > >> https://arrow.apache.org/adbc/main/cpp/driver_manager.html> work has > > been > > >> largely targeting an app-specific implementation. Have there been any > > >> discussions of ADBC having a similar system-wide driver registration > > >> paradigm like ODBC does? > > >> > > > > > >
