<p dir="ltr">There wasn't a 'key' argument before and yes, it will change the key regardless of whether you're merging or not. Initially I added it just for the merges, but then realized that there us no conceptual reason to restrict it just to merges.</p>

<p dir="ltr">Fyi the reason you probably thought there is a key argument before is because in R shorthand of arguments is valid syntax and you were actually using 'keyby' (which has not changed). </p>
<p dir="ltr">You raise a good point that I haven't thought of that copying can be faster than sorting - I will check when that's true. It's easy to implement the copy version and I did this because I assumed it's the faster option, but if it's not then might as well copy and do this for merges only. <br>

</p>
<div class="gmail_quote">On Sep 28, 2013 11:50 PM, "Frank Erickson" <<a href="mailto:FErickson@psu.edu">FErickson@psu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi,<div><br></div><div>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...</div><div><a href="http://r-forge.r-project.org/tracker/index.php?func=detail&aid=4675&group_id=240&atid=978" target="_blank">http://r-forge.r-project.org/tracker/index.php?func=detail&aid=4675&group_id=240&atid=978</a><br>


</div><div><a href="http://stackoverflow.com/a/19074195/1191259" target="_blank">http://stackoverflow.com/a/19074195/1191259</a><br></div><div>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.</div>


<div><br></div><div>@eddi:</div><div><br></div><div>+1. Yeah, I like this new option and will probably use it.<br></div><div><br></div><div>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.<br>


</div><div><br></div><div>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.</div>


<div><br></div><div>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.<br>


</div><div><br></div><div>Best,</div><div><br></div><div>Frank</div></div>
<br>_______________________________________________<br>
datatable-help mailing list<br>
<a href="mailto:datatable-help@lists.r-forge.r-project.org">datatable-help@lists.r-forge.r-project.org</a><br>
<a href="https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help" target="_blank">https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/datatable-help</a><br></blockquote></div>