I’m planning to submit dplyr 0.6.0 to CRAN on May 11 (in four weeks time). In preparation, I’d like to announce that the release candidate, dplyr 0.5.0.9002 is now available. I would really appreciate it if you’d try it out and report any problems. This will ensure that the official release has as few bugs as possible.
Installation#
Install the pre-release version with:
|
|
If you discover any problems, please file a minimal reprex on GitHub . You can roll back to the released version with:
|
|
Features#
dplyr 0.6.0 is a major release including over 100 bug fixes and improvements. There are three big changes that I want to touch on here:
-
Databases
-
Improved encoding support (particularly for CJK on windows)
-
Tidyeval, a new framework for programming with dplyr
You can see a complete list of changes in the draft release notes .
Databases#
Almost all database related code has been moved out of dplyr and into a new package, dbplyr . This makes dplyr simpler, and will make it easier to release fixes for bugs that only affect databases.
To install the development version of dbplyr so you can try it out, run:
|
|
There’s one major change, as well as a whole heap of bug fixes and minor improvements. It is now no longer necessary to create a remote “src”. Instead you can work directly with the database connection returned by DBI, reflecting the robustness of the DBI ecosystem. Thanks largely to the work of Kirill Muller (funded by the R Consortium ) DBI backends are now much more consistent, comprehensive, and easier to use. That means that there’s no longer a need for a layer between you and DBI.
You can continue to use src_mysql(), src_postgres(), and src_sqlite() (which still live in dplyr), but I recommend a new style that makes the connection to DBI more clear:
|
|
This is particularly useful if you want to perform non-SELECT queries as you can do whatever you want with DBI::dbGetQuery() and DBI::dbExecute().
If you’ve implemented a database backend for dplyr, please read the backend news
to see what’s changed from your perspective (not much). If you want to ensure your package works with both the current and previous version of dplyr, see wrap_dbplyr_obj() for helpers.
Character encoding#
We have done a lot of work to ensure that dplyr works with encodings other that Latin1 on Windows. This is most likely to affect you if you work with data that contains Chinese, Japanese, or Korean (CJK) characters. dplyr should now just work with such data.
Tidyeval#
dplyr has a new approach to non-standard evaluation (NSE) called tidyeval. Tidyeval is described in detail in a new vignette about programming with dplyr but, in brief, it gives you the ability to interpolate values in contexts where dplyr usually works with expressions:
|
|
This will make it much easier to eliminate copy-and-pasted dplyr code by extracting repeated code into a function.
This also means that the underscored version of each main verb (filter_(), select_() etc). is no longer needed, and so these functions have been deprecated (but remain around for backward compatibility).

