One thing I often do in production code after a merge is validating my assumptions on unique keys and relationship between them in both merge inputs (i.e. cardinality checks). For example, if I have duplicated keys in one data frame and perform an inner join, I end up with more rows that both input tables had, which might come as a surprise and can cause downstream problems if I don't manually assert this.
In a script, checking these conditions and raising a (helpful) error can take a few lines of code quickly, let alone the verbosity if you have multiple sequential joins. For that reason, I propose to offer the user the option to opt in for cardinality validation as part of the join, very much like Python's pandas implemented this:
import pandas
pandas.merge(..., validate = 'one_to_one')
In {dplyr}, it could be
dplyr::inner_join(..., validate = "1:N")
Maybe we could the official abbreviations (not sure they even exist, maybe case insensitive), e.g. 1:n, m:n etc.
If this is out of scope for {dplyr}, maybe it's something for @krlmlr in {dm}?
One thing I often do in production code after a merge is validating my assumptions on unique keys and relationship between them in both merge inputs (i.e. cardinality checks). For example, if I have duplicated keys in one data frame and perform an inner join, I end up with more rows that both input tables had, which might come as a surprise and can cause downstream problems if I don't manually assert this.
In a script, checking these conditions and raising a (helpful) error can take a few lines of code quickly, let alone the verbosity if you have multiple sequential joins. For that reason, I propose to offer the user the option to opt in for cardinality validation as part of the join, very much like Python's pandas implemented this:
In {dplyr}, it could be
Maybe we could the official abbreviations (not sure they even exist, maybe case insensitive), e.g.
1:n,m:netc.If this is out of scope for {dplyr}, maybe it's something for @krlmlr in {dm}?