In dplyr 1.0.0 the .groups argument was added to summarise to indicate what should happen with a grouping consisting of multiple variables. Unfortunately, this special argument does not seem to be recognized by the dbplyr::summarise implementation. Adding it results in a column .groups being added to the output.
This makes it difficult to write warning-free, generic code in the sense that it can take either a data.frame (or tibble) or an object returned from tbl.
The below code is a short illustration of the problem (using SQLite for testing purposes, the problem also exists for different databases/connectors)
The first call to my_summary yields something like
# A tibble: 6 x 3
a b y_
* <chr> <dbl> <dbl>
while the second one returns
# A tibble: 6 x 4
# Groups: a [4]
a b y_ .groups
<chr> <dbl> <dbl> <chr>
with the .groups column being set to "drop". Expected behaviour: both calls should return a tibble with the same schema.
In a way I suspect that there were always inconsistencies here (i.e. grouping dropping completely in dbplyr/SQL after a summarise vs. only the last variable being removed in dplyr) that are hard to fix, but recognizing .groups on the dbplyr side would be a nice consistency improvement.
The text was updated successfully, but these errors were encountered:
In dplyr 1.0.0 the
.groups
argument was added tosummarise
to indicate what should happen with a grouping consisting of multiple variables. Unfortunately, this special argument does not seem to be recognized by thedbplyr::summarise
implementation. Adding it results in a column.groups
being added to the output.This makes it difficult to write warning-free, generic code in the sense that it can take either a data.frame (or tibble) or an object returned from
tbl
.The first call to
my_summary
yields something likewhile the second one returns
with the
.groups
column being set to"drop"
. Expected behaviour: both calls should return atibble
with the same schema.In a way I suspect that there were always inconsistencies here (i.e. grouping dropping completely in dbplyr/SQL after a summarise vs. only the last variable being removed in dplyr) that are hard to fix, but recognizing
.groups
on the dbplyr side would be a nice consistency improvement.The text was updated successfully, but these errors were encountered: