镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

data.table(key=) doesn't allow whitespaces #4292

Closed

Description

@shrektan

OK

data.table(A=1,B=2,C=3, key="A,B")

This fails

data.table(A=1,B=2,C=3, key="A, B")
#  Error in setkeyv(ans, key) : some columns are not in the data.table:  B 

But I think it should work.

Activity

  1. Henrik-P commented on Mar 10, 2020

    @Henrik-P

    Please note that also by also accepts

    a single character string containing comma separated column names

    ...but here the help text is more informative than for key: it's explicit about the possibility for leading or trailing spaces in column names (although I think that would be a terrible habit):

    where spaces are significant since column names may contain spaces even at the start or end

    In addition, I find the error message in by slightly clearer: because the problematic column name is quoted in the error message, it's easier to spot a space here than in the corresponding error message for key, where the name is unquoted.

    as.data.table(mtcars)[ , .N, by = "vs, am"]
    # Error in eval(bysub, x, parent.frame()) : object ' am' not found
    

    I think that the specification of column names using "a single character string containing comma separated column names" should behave similarly in key and by. That said, I wouldn't miss this option to specify columns if it was deprecated.

  2. ColeMiller1 commented on Mar 10, 2020

    @ColeMiller1
    Contributor

    I agree with @Henrik-P. A better way may be to export the .() functionality which would take one more character to do what you are proposing.

    .(A, B)
    "A, B"
    

    FWIW, I am going to propose to deprecate the comma delimited feature in the by arg in another PR. I'll make a separate issue for that discussion.

  3. jangorecki commented on Mar 10, 2020

    @jangorecki
    Member

    I would not use .(), then we don't need to substitute. And personally I would deprecate scalar string for multiple columns, both in key and in by, of course very slowly.

  4. shrektan commented on Mar 10, 2020

    @shrektan
    Author
  5. ColeMiller1 commented on Mar 11, 2020

    @ColeMiller1
    Contributor

    @shrektan I do not follow. Not sure if there is a question about a column name containing a comma. But some column names do sometimes have white space.

    @jangorecki using substitute is 5 times slower - it takes 2.6 microseconds. In the long run I still see the col_select being able to be used in situations like these.

    Actual benchmark data
    fx_sub = function(x) {
      all.vars(substitute(x))
      }
    
    bench::mark(
      fx_sub(.(A, B)),
      c('A','B'),
      time_unit = 'ns'
    )
    # A tibble: 2 x 13
    ##nano seconds
    ##  expression        min median
    ## <bch:expr>      <dbl>  <dbl>
    ##1 fx_sub(.(A, B)) 2100.  2600.
    ##2 c("A", "B")      400.   500.
  6. MichaelChirico commented on Jul 11, 2025

    @MichaelChirico
    Member

    I would consider key=<string> support in maintenance mode -- we don't really plan to deprecate it, but neither will we do more feature work like this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions