Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import #4 : from DB connection #4

Open
pvictor opened this issue Aug 10, 2020 · 4 comments
Open

Import #4 : from DB connection #4

pvictor opened this issue Aug 10, 2020 · 4 comments

Comments

@pvictor
Copy link
Member

pvictor commented Aug 10, 2020

Goal : use a DBI connection to import a table

Features:

  • Use existing DBI connection from Global Env ?
  • Interface to connect to a DB with DBI::dbConnect ?
  • Get schemas and tables in DB and let the user choose
@shahreyar-abeer shahreyar-abeer self-assigned this Aug 15, 2020
@struckma
Copy link

struckma commented Mar 3, 2022

+1 -- Maybe, I can help here and also with my own fequest #42

@pvictor
Copy link
Member Author

pvictor commented Mar 4, 2022

Your thoughts on what features this module should include are welcomed.

My first two concerns:

  • How to connect ? Using an already existing connection object or with a GUI asking for host, port, etc ? How to select the driver ?
  • How to list schemas if there are schemas, or how to allow users to find tables easily ?

@struckma
Copy link

struckma commented Mar 7, 2022

Dear @pvictor, after a short discussion with my database colleague, we agreed that providing a GUI for connecting to arbitrary databases would clearly be out of scope for your widget, what do you think? Therefore, we could offer a drop-down with existing opened connections from the global environment or this RStudio-Connection panel. Maybe, I find time for searching for GUI packages helping with creating such connections, so that we could optionally use such a package for adding custom connections. Maybe, I consider such important, that I would start writing such a widget, not sure about the latter yet.

Regarding the selection of a schema, the SQL standard lacks a default way of retrieving these. However, according to https://en.wikipedia.org/wiki/Information_schema , the Information_schema-table is provided by some of the most prominent DBMS. However, maybe, we need to also address some of the other databases too (Oracle, DB2) -- not sure about that. However, having something working for PostgreSQL, MySQL/MariaDB and MSSQL is better than not having anything, at least in my opinion. However, DBI should be responsible for this, and it has dbListTables and dbListObjects, so we maybe should just use these functions for a first implementation?

@struckma
Copy link

Digged deeper a bit for abstract solutions (not for the first time). I would come to the conclusion, that this issue needs specific widgets for each DBI driver, because they differ too much from each other. Also, this way, the driver-selection drop-down could be filled based on manually defined rules like "PostgreSQL is available if RPostgreSQL or RPostgres are installed" . So, I would start with a specific widget for PostgreSQL, maybe later other DBI packages could be amended.

NB: Although, I found a way to find all installed DBI drivers, still, the connection parameters cannot be easily found out.
DBI in R really would profit from some metadata standards to define specific arguments needed for a connection using a given driver package, and given the complexity of my driver-finder code, also the information, which DBIDrivers a package implements, if any, should be somewhere in a driver's package's metadata, maybe, similar to RStudio-Addons, in a specific additional file in the inst-directory, or as a Config/... entry in DESCRIPTION (I have seen the latter lately e.g. at https://r-pkgs.org/description.html, has the CRAN-policy about DESCRIPTION been extended?).

@shahreyar-abeer shahreyar-abeer removed their assignment Mar 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants