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

Add additional cloud provider driver "helper" functions #878

Open
atheriel opened this issue Jan 6, 2025 · 3 comments
Open

Add additional cloud provider driver "helper" functions #878

atheriel opened this issue Jan 6, 2025 · 3 comments
Labels
feature a feature request or enhancement

Comments

@atheriel
Copy link
Collaborator

atheriel commented Jan 6, 2025

The odbc::databricks() and odbc::snowflake() functions have been pretty successful, because we've been able to stuff a lot of unpleasant auth and configuration details in there that users would previously have to copy around manually.

There are several other obvious candidates for "cloud provider helper functions", too:

  • redshift() and rds() helpers that handle AWS IAM credentials and maybe integrate with the paws package; and
  • A sqlserver() helper that picks up on Azure credentials.

I think we should try to build these out over time.

@atheriel atheriel added the feature a feature request or enhancement label Jan 6, 2025
@hadley
Copy link
Member

hadley commented Jan 6, 2025

I think we should do this for all databases, since it's often not easy to figure out the needed parameter names.

@atheriel
Copy link
Collaborator Author

atheriel commented Jan 7, 2025

Something we could do for non-cloud provider databases in those helper functions would be system keyring support, and better hygiene around passwords in general.

I think right now code snippets suggest doing things like pwd = rstudioapi::askForPassword(), but we don't really formalise that advice like we can with the helper functions. E.g. I can imagine code omitting a password like the following:

dbConnect(odbc::postgres(), server = "pgsql.internal", uid = "aaron")

would call the equivalent of

keyring::key_get("psql.internal", username = "aaron")

and then finally askpass::askpass() in interactive contexts.

@hadley
Copy link
Member

hadley commented Jan 8, 2025

Yeah, we just need to figure out which package should be responsible for this infrastructure and design some conventions around it. I suspect that this should be keyring's responsibility .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement
Projects
None yet
Development

No branches or pull requests

2 participants