Could I merge two collections in mongodb aggregate?

help
1

I have two collections in mongodb.

A: [
  { name: 'A' }
]
B: [
  { name: 'B' }
]
---
MergeCollection: [
  { name: 'A' },
  { name: 'B' }
]

Could I merge A+B collections?

2

You can query them like joins in SQL using $lookup

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/

3

thanks @rjdavid for your reply.
I am not clear that $lookup could do this.
($lookup like join in Sql-Relationship)
Could example???

4

https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/#examples

5

I understand that $lookup is for Relationship

db.orders.aggregate([
   {
     $lookup:
       {
         from: "inventory",
         localField: "item",
         foreignField: "sku",
         as: "inventory_docs"
       }
  }
])

But my case don’t relationship, I would like to merge data of two collections.
Could you example code here?

6

Define what you mean by merge.

You could join two collections with the aggregation pipeline and put the result into a new collection.

7

You seem to be looking for the MongoDB equivalent of an SQL UNION but unfortunately there isn’t one.

Possibly the only way to address your use case would be to do the merging in the app code.

If you can’t afford to fetch them sequentially, you could use Future to fetch them in a non-blocking fashion:

const Future = Npm.require('fibers/future');

const merged = [];

const fetchTasks = [A, B].map(
    collection => () => collection.find().forEach(it => merged.push(it))
);

Future.wait(fetchTasks);

return merged;
8

Thanks, I will try :sunny:
Excuse me, what is fibers/future?

9

Meteor uses node-fibers underneath to make it possible to write synchronous-looking code syntax while still making use of Node’s asynchronous/non-blocking code execution. That’s how Meteor’s APIs avoid callbacks.

While “Fiber” is a low-level concept, it enables an abstraction called Future, which can thought of as an alternative to Promise. Promise is obviously the more popular concept, and now a core JS api, but that wasn’t the case when Meteor decided to use fibers and so we’re kinda stuck with it (perhaps it would require “Meteor 2.0” to get rid of it, but I digress).

Wherever you can use async/await or Promise api, you should prefer them over Future. But unfortunately for most of Meteor’s core APIs that could mean quite a bit of boilerplate, whereas using them with Future is often quite concise like I showed in the example. The fibers library included by Meteor is available for your app code via Npm.require.

Update:
It’s surprising Meteor’s documentation doesn’t say anything about its use of fibers. There’s some description in the guide though, but it deserves more prominence

1 Like
10

Very thanks :blush: :sunny: