The internal `client.s` property is no longer necessary to create the database object. If `MongoClient.prototype.db` is called without arguments, it will use the database name from the connection URI
(https://jira.mongodb.org/projects/NODE/issues/NODE-1258).
Fixes#9827.
The client.s.databaseName property appears to have been introduced a long
time ago (in 2014), so it seems reliable:
14fd60b99d
The use of client.s.options.dbName was only recently introduced in #9790,
since the MongoDB.connect callback now receives a MongoClient object
rather than a Db object. Not sure if client.s.options.dbName was ever
reliable, but at least we know when the problem started.
Workaround for #8598: the Node Mongo driver has at least one bug that can lead
to query callbacks never getting called (even with an error) when leadership
failover occur.
Note that while we did fix one Node Mongo driver bug and close#8598, we've
heard reports that there are more similar issues, so this workaround seems like
a good plan.
* Update MongoDB driver to 3.0.5
* Use `MongoClient` instead of `Db` in Meteor Tool
* Update `mongo-livedata` test for new MongoDB driver version
* Consider `BulkWriteError` when checking MongoDB errors
Since jquery used to be a core package, and the most recent Meteor release
(1.6.1.1) imposed the ~1.11.11 constraint (note the ~), jquery@1.12.1
won't be usable with Meteor 1.6.x until it is republished after the next
Meteor release, which will no longer constrain the jquery version, because
jquery is no longer a core package (#9607).
In order to publish these two packages sooner rather than later, we need
to relax their jquery version constraints, because we don't want to
publish jquery@1.12.1 yet. The relaxed @1.11.11 constraints in these
package.js files will remain compatible with jquery@1.12.1, so this change
should be safe for the forseeable future.
Workaround for #8598: the Node Mongo driver has at least one bug that can lead
to query callbacks never getting called (even with an error) when leadership
failover occur.
* Downgrade uglify-es from 3.3.10 to 3.3.9 (latest published).
PR #9652 by @klaussner upgraded `uglify-es` from 3.2.2 to 3.3.10 to fix
issue #9647, but 3.3.9 is the latest version published to npm, and 3.3.10
seems to suffer from this bug: https://github.com/mishoo/UglifyJS2/issues/2896
For that reason, I think it might be best to downgrade `uglify-es` to
3.3.9, at least until 3.3.11 is published.
Since this bug causes `uglify-es` to throw during minification, the
`meteorJsMinify` function falls back to Babel's minifier, which is known
to use massive amounts of memory, and may be contributing to OOM problems
such as #9568. In other words, there's a chance that this downgrade will
help with #9568.
* Also bump standard-minifier-js package version.
