Why does X[Y] join of data.tables not allow a full outer join, or a left join?

To quote from the data.table FAQ 1.11 What is the difference between X[Y] and merge(X, Y)?

X[Y] is a join, looking up X's rows using Y (or Y's key if it has one) as an index.

Y[X] is a join, looking up Y's rows using X (or X's key if it has one)

merge(X,Y) does both ways at the same time. The number of rows of X[Y] and Y[X] usually differ, whereas the number of rows returned by merge(X,Y) and merge(Y,X) is the same.

BUT that misses the main point. Most tasks require something to be done on the data after a join or merge. Why merge all the columns of data, only to use a small subset of them afterwards? You may suggest merge(X[,ColsNeeded1],Y[,ColsNeeded2]), but that requires the programmer to work out which columns are needed. X[Y,j] in data.table does all that in one step for you. When you write X[Y,sum(foo*bar)], data.table automatically inspects the j expression to see which columns it uses. It will only subset those columns only; the others are ignored. Memory is only created for the columns the j uses, and Y columns enjoy standard R recycling rules within the context of each group. Let's say foo is in X, and bar is in Y (along with 20 other columns in Y). Isn't X[Y,sum(foo*bar)] quicker to program and quicker to run than a merge of everything wastefully followed by a subset?

If you want a left outer join of X[Y]

le <- Y[X]mallx <- merge(X, Y, all.x = T)# the column order is different so change to be the same as `merge`setcolorder(le, names(mallx))identical(le, mallx)# [1] TRUE

If you want a full outer join

# the unique values for the keys over both data setsunique_keys <- unique(c(X[,t], Y[,t]))Y[X[J(unique_keys)]]##   t  b  a## 1: 1 NA  1## 2: 2 NA  4## 3: 3  9  9## 4: 4 16 16## 5: 5 25 NA## 6: 6 36 NA# The following will give the same with the column order X,YX[Y[J(unique_keys)]]

@mnel's answer is spot on, so do accept that answer. This is just follow up, too long for comments.

As mnel says, left/right outer join is obtained by swapping Y and X: Y[X] -vs- X[Y]. So 3 of the 4 join types are supported in that syntax, not 2, iiuc.

Adding the 4th seems a good idea. Let's say we add full=TRUE or both=TRUE or merge=TRUE (not sure the best argument name?) then it hadn't occurred to me before that X[Y,j,merge=TRUE] would be useful for the reasons after the BUT in FAQ 1.12. New feature request now added and linked back here, thanks :

FR#2301 : Add merge=TRUE argument for both X[Y] and Y[X] join like merge() does.

Recent versions have sped up merge.data.table (by taking a shallow copy internally to set the keys more efficiently, for example). So we are trying to bring merge() and X[Y] closer, and provide all options to user for full flexibility. There are pros and cons of both. Another outstanding feature request is :

FR#2033 : Add by.x and by.y to merge.data.table

If there are any others, please keep them coming.

By this part in the question :

why not use the merge syntax for joins rather than the match function's nomatch parameter?

If you prefer merge() syntax and its 3 arguments all,all.x and all.y then just use that instead of X[Y]. Think it should cover all the cases. Or did you mean why is the argument a single nomatch in [.data.table? If so, it's just the way that seemed natural given FAQ 2.14 : "Can you explain further why data.table is inspired by A[B] syntax in base?". But also, nomatch only takes two values currently 0 and NA. That could be extended so that a negative value meant something, or 12 would mean use the 12th row's values to fill in NAs, for example, or nomatch in future could be a vector or even itself a data.table.

Hm. How would by-without-by interact with merge=TRUE? Perhaps we should take this over to datatable-help.

This "answer" is a proposal for discussion: As indicated in my comment, I suggest adding a join parameter to [.data.table() to enable additional types of joins, ie: X[Y,j,join=string]. In addition to the 4 types of ordinary joins, I also suggest to support 3 types of exclusive joins, and the cross join.

The join string values (and aliases) for the various join types are proposed to be:

1. "all.y" and "right" -- right join, the present data.table default (nomatch=NA) - all Y rows with NAs where there is no X match;

2. "both" and "inner" -- inner join (nomatch=0) - only rows where X and Y match;

3. "all.x" and "left" -- left join - all rows from X, NAs where no Y match:

4. "outer" and "full" -- full outer join - all rows from X and Y, NAs where no match

5. "only.x" and "not.y" -- non-join or anti-join returning X rows where there is no Y match

6. "only.y" and "not.x" -- non-join or anti-join returning Y rows where there is no X match
7. "not.both" -- exclusive join returning X and Y rows where there is no match to the other table, ie an exclusive-or (XOR)
8. "cross" -- cross join or Cartesian product with each row of X matched to each row of Y

The default value is join="all.y" which corresponds to the present default.

The "all", "all.x" and "all.y" string values correspond to merge() parameters. The "right", "left", "inner" and "outer" strings may be more amenable to SQL users.

The "both" and "not.both" strings are my best suggestion at the moment -- but someone may have better string suggestions for the inner join and exclusive join. (I'm not sure if "exclusive" is the right terminology, correct me if there is a proper term for an "XOR" join.)

Use of join="not.y" is an alternative for X[-Y,j] or X[!Y,j] non-join syntax and maybe more clear (to me), although I'm not sure if they are the same (new feature in data.table version 1.8.3).

The cross join can be handy sometimes, but it may not fit in the data.table paradigm.