Why does Collection._ensureIndex() add "safe": true?

Meteor’s Collection._ensureIndex() has a different effect than MongoDB’s createIndex(). This is not suprising since _ensureIndex() probably calls MongoDB’s deprecated ensureIndex() and Meteor’s _ensureIndex() is undocumented and private (starts with an underscore).

Here’s an example index created with Meteor’s AppLogs._ensureIndex({createdAt:1},{unique:false}) during app startup in server-side code (AppLogs is a collection):

{
    "v": 1,
    "key": {
        "createdAt": 1
    },
    "name": "createdAt_1",
    "ns": "staging.applogs",
    "safe": true
}

And here’s the same index, created from the mongo console with db.applogs.createIndex({createdAt:1}):

{
    "v": 1,
    "key": {
        "createdAt": 1
    },
    "name": "createdAt_1",
    "ns": "staging.applogs",
    "safe": true
}

So, what’s that "safe": true all about?

I’m using Meteor 1.1.0.2 and MongoDB 2.6.9 (installed on the system… MONGO_URL is set).

It is a driver option that translates as the mongodb write concern option which means if any error occurs, we want to know about it and the callback functions should return the error instead of silently swallowing it.

Sure, I’ve heard about write concern settings, but… on an index?

Do you have a reference to documentation explaining this? I looked over createIndex() in the latest MongoDB docs and _ensureIndex() in some of the MongoDB 2.4 docs and couldn’t find any reference to the safe option.

I think this comes from the node mongo driver that meteor uses, but frankly
I don’t quite get why it gets stored like that.

I checked the repo: where it gets set (in several places). Sadly, there’s no real supporting annotation for the meaning or use case. In the absence of that and given its use on the db connection object I tend to agree with @serkandurusoy’s reply.

Not very helpful, I know. :worried:

I think this is just a no-op bug / typo. I sent a pull request to fix it.

1 Like

Wow! So it actually is not related with write concerns at all!