Our current testing on Mongo is less complete than it could be and these
tests, particularly the `mongo with multiple --port numbers` test which does
actual writes to the database, should help with that.
Note that these tests are separate from the `mongo` package tests which are
much more extensive and test more advanced mongo functionality, but it's
good to have some basic Windows tests in place within the `self-test`
infrastructure.
cc @benjamn
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.
This functionality was originally intended to allow importing
compiled-to-JS modules from `node_modules`, by precompiling any modules
found in top-level npm packages, as long as a Meteor compiler plugin was
registered for the module's file extension.
As discussed in #9800, this extra compilation burden can be non-trivial,
especially if you happen to install an npm package such as `less`, which
contains hundreds of `.less` files in the `node_modules/less/test/`
directory.
More generally, this functionality was an early attempt to enable
selective compilation of `node_modules` directories, but it was not a good
solution to that problem, because in almost all cases the extra
compilation was unwanted.
Meteor 1.7 (formerly known as 1.6.2) will give full control over selective
compilation of `node_modules` back to the application developer (#9771),
which should afford a much better solution to this problem. If you've
installed some `.less` or `.scss` or `.ts` files from npm into your
`node_modules` directory, just create a symlink to the package directory
within your application, and those modules will be compiled and become
importable by other JS modules, as if they were part of the application.
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.
If the max size is too large (at least on windows_x86), the process
silently exits without doing anything, which is arguably worse than just
using the default max space (i.e., not passing the option).
https://github.com/meteor/meteor-feature-requests/issues/283
The ProjectContext#_buildLocalPackages method calls
IsopackCache#buildLocalPackages which calls _ensurePackageLoaded for each
local package, so this commit exposes how long each of those
_ensurePackageLoaded calls takes (when METEOR_PROFILE is enabled).
* 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.
