Difference between new Mongo.Collection(null) on client and new Mongo.Collection('things') on client?

I’m not really clear what the difference between these two statements is (on client side only):

Things = new Mongo.Collection(null);
Things = new Mongo.Collection('things');

Both are local (client) Minimongo collections that don’t sync up with the server. What’s the difference?

The second one will throw an error as soon as you want to insert in it because it will look for the corresponding collection on the server.

You can do

Things = new Mongo.Collection('things', {connection: null});

to keep it as a client only connection.

The problem with

Things = new Mongo.Collection(null);

used to be that there can only be one collection whose minimongo collection name is null. I don’t know if that’s still an issue, but you can try that.

1 Like
new Mongo.Collection(null);

is the way to instantiate a local collection. Specifically speaking, with null the client establishes no connection to the server from the get-go. I’m not exactly sure what happens when you use a name that does not exist, but it definitely goes through some trouble to figure out that something is wrong. I’m also not sure what would happen if at some point the things collection were to be created in the DB; that would be an interesting scenario. Maybe one of the devs can answer that, but if you want to, you can dig in the codebase yourself - that’s the beauty of open-source!

I don’t think so. I just did this in the Chrome console:

Test = new Mongo.Collection('test')

And it worked, no errors.

The documentation is a bit fuzzy. Here’s what it says about passing null:

If you pass null as the name, then you’re creating a local collection. It’s not synchronized anywhere; it’s just a local scratchpad that supports Mongo-style find, insert, update, and remove operations. (On both the client and the server, this scratchpad is implemented using Minimongo.)

And here’s what it says about passing a collection name, but instantiating on the client only:

On the client (and on the server if you specify a connection), a Minimongo instance is created. Minimongo is essentially an in-memory, non-persistent implementation of Mongo in pure JavaScript. It serves as a local cache that stores just the subset of the database that this client is working with. Queries (find) on these collections are served directly out of this cache, without talking to the server.

Emphasis above is mine. This sounds like the exact same thing to me.

the second one sounds like still syncing, but with latency compensation

I don’t think so. I just did this in the Chrome console:

Test = new Mongo.Collection('test')

@ffxsam Are you sure? When I try it, I get this in the console:

insert failed: Method not found

And that’s normal because minimongo is (since it is named) assuming that there is a counterpart on the server and that there is an insert method attached to it, which is not the case, hence the method not found error.

Ah! Yes, you’re right. I can create the collection, but when I try to insert into it, I get an error.

No, you can have many collections, but you must keep a reference to each of them since they are unamed.
This is used by my package https://atmospherejs.com/vjau/localcollections-persister to act like a powerful local state store which persist between hot code pushes.

1 Like

Insert fails but find works and you can publish to it from the server.

Mongo.Collection._publishCursor(query, this, ‘test’);

So it’s possible to create a client only collection and publish to it.

Nice to know, I guess this has been one of those things that I’ve learned very early on and could not unlearn :slight_smile:

See this thread about why you might want to use a client-only named collection: