Implement check_keys

[hadley]

This is very rarely desirable (however we will need an option to turn the warning off in case you do actually want it).

cc @jennybc

[krlmlr]

I wonder how to achieve this for SQL sources.

[hadley]

Or if keys are missing (#1590)

[hadley]

For now, let's make this an explicit check_keys() function. This could be a simple wrapper around count - the main challenge will be a nice output, particularly if there are many problems.

[krlmlr]

I have been using a similar functionality in my scripts. I think it suffices if the first few collisions are reported.

Should check_keys() call compute() for SQL sources?

[rtaph]

@hadley I agree it is rarely desirable to require that both x and y not have duplicates, but would argue it is common not to want the keys in y to have duplicates.

When left joining in particular, being able to require a non-duplicative property in the foreign key y ensures that conceptual meaning of a row is preserved through the join operation.

[hadley]

A natural implementation would be something like this:

check_keys <- function(.data, ...) {
  keys <- select(.data, ...)
  keys <- ungroup(keys)
  keys <- mutate(keys, `__id` = 1:row_number())

  # Check that keys are unique
  dups <- group_by_all(keys)
  dups <- summarise(dups, n = n())
  dups <- filter(dups, n > 1)
  dups_keys <- semi_join(keys, dups, by = names(keys))
  
  # Check that keys are not missing
  miss <- filter_all(keys, is.na)
  miss_keys <- semi_join(keys, dups, by = names(keys))
}

But this requires both group_by_all() and filter_all()

[hadley]

I think we'll probably need two functions: one that throws an error if anything is wrong, the other should return a tibble with one row per problem.

[krlmlr]

Should this be part of tidyr, because we're only using exported verbs here? How does this interact with set_key() (#1792)?

[romainfrancois]

We have group_by_all and filter_all now. I don't really understand what this is about though.

[krlmlr]

I think this is about a utility function that verifies if a selection of "key columns" defines a key on the tibble, i.e. that for each unique combination of values in the "key columns" there is at most one row.

[romainfrancois]

Something like this then conceptually using some of the new tools from #3574

check_keys <- function(.data, ...){
  group_by(.data, ...) %>% 
    group_rows() %>% 
    lengths() %>% 
    all(. == 1L)
}

mtcars %>% 
  check_keys(mpg, cyl, qsec)

Internalizing this by reusing some of the code from group_by would be quicker.

[krlmlr]

Maybe we can just look at group_data() ?

[romainfrancois]

what do you mean ? instead of group_rows ?

[hadley]

Just leave this one for me - it's more of a user interface issue.

[hadley]

I now think this is out of scope for dplyr, and better belongs in its own package, e.g. https://github.com/krlmlr/dm.