rows_delete implementation for data.table backends.
# S3 method for dtplyr_step
rows_delete(x, y, by = NULL, ..., unmatched, copy = FALSE, in_place = FALSE)An object of the same type as x. The order of the rows and columns of x
is preserved as much as possible. The output has the following properties:
rows_update() and rows_patch() preserve the number of rows;
rows_insert(), rows_append(), and rows_upsert() return all existing
rows and potentially new rows; rows_delete() returns a subset of the
rows.
Columns are not added, removed, or relocated, though the data may be updated.
Groups are taken from x.
Data frame attributes are taken from x.
If in_place = TRUE, the result will be returned invisibly.
A pair of data frames or data frame extensions (e.g. a tibble).
y must have the same columns of x or a subset.
An unnamed character vector giving the key columns. The key columns
must exist in both x and y. Keys typically uniquely identify each row,
but this is only enforced for the key values of y when rows_update(),
rows_patch(), or rows_upsert() are used.
By default, we use the first column in y, since the first column is
a reasonable place to put an identifier variable.
Other parameters passed onto methods.
For rows_update(), rows_patch(), and rows_delete(),
how should keys in y that are unmatched by the keys in x be handled?
One of:
"error", the default, will error if there are any keys in y that
are unmatched by the keys in x.
"ignore" will ignore rows in y with keys that are unmatched by the
keys in x.
If x and y are not from the same data source,
and copy is TRUE, then y will be copied into the
same src as x. This allows you to join tables across srcs, but
it is a potentially expensive operation so you must opt into it.
Should x be modified in place? This argument is only
relevant for mutable backends (e.g. databases, data.tables).
When TRUE, a modified version of x is returned invisibly;
when FALSE, a new object representing the resulting changes is returned.
Jasper Schelfhout