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
_______________________________________________ datatable-help mailing list [email protected] https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help
