This transition guide is aimed at backend authors. dbplyr 2.0.0 is an important release for backends because it starts the process of moving all backend generics into dbplyr (instead of some living in dplyr). This move has been designed to occur in phases to avoid sudden breakages and give backend authors plenty of time to make changes.
The current timeline is something like this:
dbplyr 2.0.0 adds a new interface for database backends. The old interface remains so all existing backends continue to work, but new packages should use the new interface, and existing backends should start the update process.
dbplyr 2.1.0 (to be released >= 6 months after dplyr 2.0.0) deprecates the old interface, so that users are encouraged to upgrade backends.
dbplyr 2.2.0 (to be released >= 12 months after dplyr 2.0.0) removes the old interface so user must upgrade backends.
A future version of dplyr will deprecate then remove the database generics.
A number of generics are no longer used so you can delete the corresponding methods:
DBI::dbWriteTable() instead of nine individual generics:
db_query_rows() was never actually used.
Making these changes are important because they ensure your backend works consistently whether you use it through DBI or dplyr.
dbplyr 2.0.0 draws inspiration from the idea of an edition so that to tell dbplyr to use the new generics, you need to do two things:
Depend on dbplyr 2.0.0 in your
Imports: dbplyr (>= 2.0.0). This ensures that when someone installs your package they get the latest version of dbplyr.
Provide a method for the
#' @importFrom dbplyr dbplyr_edition #' @export dbplyr_edition.myConnectionClass <- function(con) 2L
This tells dbplyr to use the new generics instead of the old generics.
Then you’ll need to update your methods, following the advice below.
There are a number of dplyr generics that generate then execute SQL. These have been replaced by dbplyr generics that just generate the SQL (and dbplyr takes care of executing it):
If you have methods for any of those generics, you’ll need to extract the SQL generation code into a new
A number of other generics have been renamed:
If you have methods for any of these generics, you’ll need to rename.
You may also want to consider methods for the new generics in dbplyr 2.0.0:
Provide a method for
db_temporary_table() if your backend requires that temporary tables have special names.
Provide a method for
sql_join_suffix() if your backend can’t use the usual
.y suffixes in joins.