[datatable-help] new key argument to [.data.table in 1.8.11

[Frank Erickson]

Hi,

I'm just continuing a discussion with @eddi that would not fit in an SO
comment. If you want to catch up, the references are...
http://r-forge.r-project.org/tracker/index.php?func=detail&aid=4675&group_id=240&atid=978
http://stackoverflow.com/a/19074195/1191259
The SO question (scroll up on the second link) was whether there was a way
to use a "temporary" key for X in an X[Y] join.

@eddi:

+1. Yeah, I like this new option and will probably use it.

Will this also overwrite the key when using [.data.table without doing
joins? That might be backward incompatible I guess, since `key` is already
an argument to `[.data.table`. That is, will x[i,,key='B'] do anything? I
don't think that type of command has had much use until now, and adding a j
argument (that doesn't start with `:=`) always makes a copy (right?), so
maybe backward compatibility would not be an issue there.

Regarding whether it's a reasonable compromise, ... well, I'll be using it,
anyway! I don't know what the feasibility constraints are on implementing
what I initially had in mind, so I'll defer to you and the developers on
that. If "secondary keys" are implemented down the road, that would solve
this problem in most cases.

As far as when I will use it, I guess it depends on the relative cost of
making a copy vs resetting the key on x. If I use the old syntax, I make a
copy, but don't have to change x's key back at the end (one copy, one key
setting). With the new syntax, I'd have to change the key on x back
afterward (zero copies, two key settings). If I know the sorting takes a
long time (e.g., because the key is the whole set of columns), I might
still go with copying.

Best,

Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/datatable-help/attachments/20130929/989f96a5/attachment.html>