r-dbi/DBI

[Feature Proposal] allow default settings per configuration file

Closed this issue · 5 comments

Most database clients allow to set some default connection parameters (e.g., hostname, port or even credentials) via configuration file, which is located "globally" (e.g., /etc/clientname/configfile) or locally (e.g., ~/.clientname/configfile). One famous example is the mysql cli application, which can be configured by the [mysql] group within a my.cnf-file. Even some DBI "backends" already provide a similar functionality (e.g., RSQLServer). I would really like to see a similar functionality as part of this interface.

The benefits would be:

  • Avoid repeating yourself all the time. It is likely, that the same people use the same database (connection) over and over again (in different files, projects or even different users). This is also the normal case for me, I always use the same connection (same database, same username, same password).
  • A possibility to provide some defaults to new users. Imagine you are a DB(I)-newbee, and you don't know how databases work or how they can be configured. You just have to select the right backend, but the connection-information can be provided by your admin, supervisor or whoever.

Sure, there are downsides, but I think they are manageable:

  • One would be the enhanced "complexity" of the DBI, but this feature would not require a lot of additional source code or additional packages.
  • Another problem are side effects (why is this not working, the default should be...?). But this can be handled with some additional infos in the documentation.

A simple structure (like a ini-file) would be enough to provide a persistent key-value store. The DBI should search in some well defined default locations (e.g., hidden config folder in home directory, hidden file in working directory). If there are some matches, they should be parsed and the provided values should be the default values for the keys (DBI connection parameters).

What do you think? Is this too much "functionality" or too "high level" for a standard database interface? Is the additional benefit not big enough to outweigh the additional lines of code needed?

I think this creates another source of potential issues, and is therefore not worth it.

Maybe this can be (or is already) part of a helper package?

@krlmlr which helper package do you mean?

I'm not aware of a package implementing this, but maybe it already exists somewhere?

Thanks for the advice, I'll close the issue now.