Meteor-feature-requests: Upgrade to Mongo 3.4

[hwillson]

Mongo 3.4 has been stable since Nov. 2016, so we should probably start thinking about upgrading Meteor's Mongo version/drivers. Top level items to be done:

• Upgrade the meteor run bundled Mongo version to 3.4
• Update the internally used mongodb npm package to version 2.2.29
• Test to make sure the latest mongodb driver works with all major versions of Mongo, starting from 2.6

[skirunman]

Even better if we get Mongo 3.4 support in Meteor 1.6, but I assumed this would probably have to come after 1.6. The update to Mongo 3.2.14 for either 1.5.1 or 1.6 would still be great if we don't get 3.4 support in 1.6.

[hwillson]

Thanks @skirunman - I agree. I've started looking into the Mongo 3.4 upgrade, so I'll post back more details shortly.

[laosb]

Glad to see all these efforts!

[hwillson]

Hi all - just a quick update here (in-case you haven't seen the latest in PR https://github.com/meteor/meteor/pull/8864). The changes were completed, only to then find out that Mongo has discontinued support for 32-bit versions as of 3.4. Meteor on Windows is still 32-bit, so we're now at a bit of a stand still with the Mongo upgrade. Moving ahead with dropping Meteor 32-bit support is the logical course of action, but this will take some time to plan / implement. Long story short, the 3.4 upgrade is now on-hold.

[holmrenser]

I am very excited about the switch to Mongo 3.4, as it opens up a few nice aggregation pipeline features I could use! Specifically, I am thinking of using $addFields to filter the contents of nested documents based on user permissions.

Having said that, If any help with ditching 32-bit is required, I am willing to try and help out!

Edit:

Just wanted to add that Mongo 3.2 will go end-of-life in little over a year from now: https://www.mongodb.com/support-policy.

[acomito]

@hwillson So we can use $graphLookup etc. if the provider (e.g. Mlab, etc) has 3.4?

[fermuch]

@acomito you can already use any feature in Mongo if you use the raw database.

const db = Tasks.rawCollection();
const aggregate = Meteor.wrapAsync(db.aggregate, db);
const data = aggregate([
  {$match: {
     done: true,
     project: projectId,
     doneDate: {
       $gte: startDate,
       $lte: endDate
     }
   }}
])

The downside is: $graphLookup wont work on your dev enviroment, because meteor bundles mongo 3.2, but it'll work on your prod environment if your database is >=3.4.

[skirunman]

You can always install and use MongoDB 3.4 in your dev environment as well.

[santiagopuentep]

We are using mlab which is updating the databases to 3.4 on august 18. Sorry, I don't understand, is meteor still going to work even though it's 3.2?

[fermuch]

@santiagopuentep yes, Meteor will continue to work.

The problem is: Meteor supports both 32 and 64 bits, but Mongo dropped 32 bits support. Since meteor ships with Mongo, meteor needs to also drop support for 32 bits. This needs to be comunicated to the community, the tools needs to be updated to warn about the deprecation, docs need to be updated, and a lot more of stuff. Some time is needed for a deprecation like this, so mongo 3.4 might not come in the next release of meteor, but it will in the future.
There is no problem if you use mongo 3.4 on your production environment, but please note: meteor bundles mongo 3.2. If you try to use 3.4 features in your dev env, they'll fail (only on your dev env).
You can still install the latest mongo and use the env variable MONGO_URL to tell meteor to use that instead of the built-in, but you'll also need to set up a replicaSet (you can make one with just one member)

[santiagopuentep]

Super clear. Thanks!

[jmbartho]

Also, we could start using $count in the aggregation pipeline.

Most are using coll.find().count() which seems less direct.. and less efficient?

Is coll.count() available somewhere?

[crapthings]

@jmbartho

yes, collection.rawCollection().count(query, options)