An environment variable like LD_LIBRARY_PATH perhaps? =p On Tue, Apr 23, 2024, 8:40 PM Ian Cook <ianmc...@apache.org> wrote:
> What if the driver managers respected an environment variable containing a > delimited list of driver search paths? I think that would get us closer to > having true system-level configurability while mostly avoiding surprises > and inflexibility. > > Ian > > On Tue, Apr 23, 2024 at 8:22 PM David Li <lidav...@apache.org> wrote: > > > I'd rather not hard code it directly into the manager, both because this > > may surprise applications that don't want it and would be inflexible for > > applications who are looking to use it, but providing an additional list > of > > search paths that (say) Excel can configure + some platform-specific > > guidance on a standard list seems reasonable. > > > > On Wed, Apr 24, 2024, at 02:45, Ian Cook wrote: > > > 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? > > >> > >> > > >> > > > > >> > > > >> > > >
