checks can be handled by a single string parameter where uppercase letters trigger failures, lower case letters trigger warnings, and letters prefixed with ~ trigger messages:
"c" to check Conflicts of Columns
"b" like "by" checks if by parameter was given explicitely
"u" to check unicity on x (lhs)
"v" to check unicity on y (lhs)
"m" to check that all rows of x have a match
"n" to check that all rows of y have a match
"e" like expand to check that all combinations of joining columns are present in x
"f" to check that all combinations of joining columns are present in y
"l" to check that matching is consistent with levels of factor columns
parameter conflicts defines what happens when trying to eat columns that already exist (if this situation is allowed). It can be "keep_xy", "keep_x", "keep_y", or "patch" (replace values if there's a match only), we could maybe add "coalesce_xy" and "coalesce_yx" that would not focus on what matched but on where NAs are present.
We could also have a function of x and y, so "keep_x" is equivalent to ~.x, and so we don't need special values to coalesce as we can just do ~coalesce(.x,.y) or stuff like ~.x+.y.
In this case a named list could tell us how to deal differently with different conflicted columns.
for eat only:
"d" like "dots" checks that dots were used to give explicitly eaten columns
maybe an at parameter to decide where to insert the newly created columns ?
checks can be handled by a single string parameter where uppercase letters trigger failures, lower case letters trigger warnings, and letters prefixed with
~
trigger messages:"c"
to check Conflicts of Columns"b"
like "by" checks ifby
parameter was given explicitely"u"
to check unicity onx
(lhs)"v"
to check unicity ony
(lhs)"m"
to check that all rows ofx
have a match"n"
to check that all rows ofy
have a match"e"
like expand to check that all combinations of joining columns are present inx
"f"
to check that all combinations of joining columns are present iny
"l"
to check that matching is consistent with levels of factor columnsparameter
conflicts
defines what happens when trying to eat columns that already exist (if this situation is allowed). It can be"keep_xy"
,"keep_x"
,"keep_y"
, or"patch"
(replace values if there's a match only), we could maybe add"coalesce_xy"
and"coalesce_yx"
that would not focus on what matched but on where NAs are present.We could also have a function of x and y, so
"keep_x"
is equivalent to~.x
, and so we don't need special values to coalesce as we can just do~coalesce(.x,.y)
or stuff like~.x+.y
.In this case a named list could tell us how to deal differently with different conflicted columns.
for
eat
only:"d"
like "dots" checks that dots were used to give explicitly eaten columnsmaybe an
at
parameter to decide where to insert the newly created columns ?