You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For testing purposes it would be great to have something like a "virtual" connection. That is, a connection that can be created without actually connecting to a database. This connection could then be used in functions like DBI::dbQuoteLiteral() that don't need a live connection.
The dbplyr package has something like this with the simulate_*() functions. This can be useful for testing when one cannot connect locally to a specific database.
I also think/hope one could then get rid of some code duplication between dbplyr and the DBI packages, for example quoting literals is also defined in dbplyr.
The text was updated successfully, but these errors were encountered:
Thanks for raising this, good idea. For DBI you can create a class that inherits from the correct connection class, if necessary implement a dbSendQuery() method that fails. Providing the mock class would be a job for the backend packages.
For testing purposes it would be great to have something like a "virtual" connection. That is, a connection that can be created without actually connecting to a database. This connection could then be used in functions like
DBI::dbQuoteLiteral()
that don't need a live connection.The
dbplyr
package has something like this with thesimulate_*()
functions. This can be useful for testing when one cannot connect locally to a specific database.I also think/hope one could then get rid of some code duplication between
dbplyr
and the DBI packages, for example quoting literals is also defined indbplyr
.The text was updated successfully, but these errors were encountered: