Add a command to do merge on streams (opposite of without)

[rethinkdb]

Add a command to do merge on streams (opposite of without)

[mlucy]

The problem here is that the order of arguments to merge matters. The reason Joe did r.merge(..., x) instead of x.merge(...) in #43 is that otherwise it would clobber the field "rating". So we actually have two commands: a left-preferential mapped merge and a right-preferential mapped merge.

[coffeemug]

Right, I missed that. We could do two commands or a flag/enum (which I personally prefer).

[jdoliner]

I think that having a command to merges on streams isn't quite what we want. It would still be a bit unwieldy to use it for defaults in pluck which is the impetus for this bug I believe. Using this command you could do:

table.left_merge({"foo": 0, "bar" : 0}).pluck("foo", "bar")

which is definitely an improvement over a map but I'd like to have the defaulting built right in to the pluck so I could do:

table.pluck(["foo", 0], ["bar", 0])

Which just feels cleaner to me. Once we have defaulting sugar in the places we want it I don't think that a stream merge command is really useful enough to justify the sugar. If I heard about merge on a stream my first guess as to what it did wouldn't be the above behavior it would be merge sorting 2 streams together.

[coffeemug]

I don't think we should call it 'merge' or even 'left_merge'. Perhaps 'defaults' or 'unpluck'? I think such a command would be very useful, even if we did provide defaults everywhere else.

Also, the pluck(['foo', 0], ['bar', 1], 'baz') api seems pretty ugly to me. Perhaps pluck('foo', 'bar', 'baz', default=null)? A little less powerful, but seems much cleaner. If the user wants the more advanced version, they can use defaults instead.

[coffeemug]

Since merge is now polymorphic, this is effectively done (one can call merge on an object or a stream -- I actually found it to be pretty convenient in practice). Closing.