Option to instantiate R interface to database as single object

[shearerp]

This package is very exciting, kudos! I have a question about the design, stemming from this example:

dbc_init adds several functions when it initializes a database source. In this case, each will start with the lahman_ prefix.

_list: Get a list of tables _tbl: Access a table that can be worked with in dbplyr _query: Perform of a SQL query and work with the result _execute: Execute a query (such as a CREATE or DROP) _src: Retrieve a dbi_src for the database

Did you consider instead making lahman a list? When I notice myself making a group of variables with the same prefix, I often end up converting that group to a list, since it gives you autocomplete for free. It also seems potentially more aesthetically pleasing to work with one object that represents the database.

I can imagine that maybe it was an ease-of-use decision for folks who are not comfortable with lists? But perhaps it could be an option for users who are more comfortable?

Just a thought, thanks again!

[chriscardillo]

Thanks, @shearerp! Happy to hear you are enjoying the package.

dbcooper is designed to be a package to create packages, so the intent is that you would create a package to connect to your database (see the lahmancooper example). In this case, you'd still get autocomplete in one object, that one object is just the package namespace, where every function starts with lahman_.

One alternative that we could pretty easily provide would be that, instead of a list, you just use a new.env(). This would provide you with the same functionality, for example:

my_env <- new.env()
my_func <- function(){"hello!"}
assign("my_func", my_func, envir = my_env)
my_env$my_func()

Is that something an option you'd be happy with, or does the package structure suffice?