The official MongoDB Node.js driver
APACHE-2.0 License
Bot releases are visible (Hide)
The MongoDB Node.js team is pleased to announce version 3.4.0 of the driver
The major functionality introduced in this release, and indeed the reason for the minor version bump, is full support for MongoDB's Client Side Field Level Encryption. The bulk of the support comes through an addon module mongodb-client-encryption, please refer to the reference documentation for more details.
This release also introduces a number of new connection string options related to TLS. In order to unify uri options across all MongoDB drivers, and to better signal the technology the driver is actually using, all ssl
related options now have a corresponding tls
variant. NOTE: your application will not break if you continue to use the ssl
variants, but deprecation warnings will be introduced prior to the 4.x driver release.
@adityapatadia initially pointed out that these tls
variants had no effect, now they do. Thank you @adityapatadia!
A critical bug was found by @ephemer with the recently introduced "mongos discovery", where a typo caused DNS polling to occur at very fast intervals.
Additionally, user @mpilar identified and fixed a bug with our mongodb+srv
parsing, where user-provided client options were not overriding those provided by a TXT record lookup.
Thank you very much @ephemer and @mpilar!
@adityapatadia also helped find a bug in the server selection code which rendered selection with a nearest
read preference non-functional. Thanks again @adityapatadia!
A small bug was fixed causing errors in an unordered bulk write to be reported in incorrect order. If an error occurs in a bulk write now, then it will show up in the writeErrors
field of the resulting BulkWriteError
with an index that corresponds to the position the operation had in the initial input.
The MongoDB Node.js team is pleased to announce version 3.3.5 of the driver
This patch release includes additional fixes for the regression in the unified topology discovered in v3.3.2, expanding our testing infrastructure to include a simulated workload during failover testing. There was a bug when connecting to single-node replicasets which could result in a stack overflow which was corrected. Additionally, events and options which are incompatible with the unified topology will now emit a warning message.
The release also includes a fix submitted by @mpilar, who found an inconsistency in our implementation of the "Initial Seedlist Discovery" specification. An authSource
specified in the options passed to MongoClient
would be overridden by an authSource
provided in the TXT record checked during initial seedlist discovery over SRV. Thank you very much Miguel!
BulkWriteError
is now exported at the top level of the module so that users can catch them easily. Additionally, a fix was made to ensure that the index of operations passed into an unordered
bulk operation were preserved when reporting possible errors in the future.
The MongoDB Node.js team is pleased to announce version 3.3.4 of the driver
This release primary consists of improvements to the "unified topology". In particular, a regression with interaction between the connection pool and topology could result in servers which "go away" (due to network error, for example) would not return, resulting in a MongoTimeoutError
.
The MongoDB Node.js team is pleased to announce version 3.3.0 of the driver
This latest release brings support for features in the newly released MongoDB v4.2:
$merge
operatorThe Driver has supported connecting to a cluster using an SRV record since version 3.0. Prior to now, we would only resolve the SRV record when initially connecting. This was fine for single replica sets, as the driver is able to discover new members added after initial connect from any member of a replica set. However, in a sharded deployment, individual mongos processes do not have an awareness of each other. This means that if the deployment changes in a shared cluster, the driver would have no way of knowing without disconnecting and connecting with a new client.
Starting in 3.3, if a driver connects to a sharded cluster with an SRV record, we will now periodically check that SRV record for any changes in the deployment, and update the client-side connections accordingly.
**NOTE: This feature is only available when starting a client with { useUnifiedTopology: true }
**
The driver now has support for MongoDB Client-Side Encryption. This requires installing the mongodb-client-encryption
npm package in your project.
mongodb-core
into node-mongodb-native
Up until this release, the mongodb
driver has consisted of two components:
mongodb-core
: The low-level engine of the driver.node-mongodb-native
: The API layer of the driver, published as mongodb
Over time, this separation has done more harm than good, and has led to increased development time for repairing bugs and implementing new features. Starting in the 3.3 release of mongodb
, we have merged mongodb-core
into node-mongodb-native
, removing this barrier to development.
The MongoDB Node.js team is pleased to announce version 3.2.1 of the driver.
Due to a publishing snafu v3.2.1 was immediately published without a proper v3.2.0 release
The Topology
class no longer uses a callback store, instead relying on a server selection loop for operation execution. This means failed operations will fail faster, with more accurate stack traces and specifics about the failure. It generally makes it much easier to reason about what the driver is doing each time an operation is executed.
You can enable it with the useUnifiedTopology
feature flag passed to your MongoClient
constructor, like so:
const client = MongoClient('mongodb://localhost:27017', { useUnifiedTopology: true });
This topology layer will replace the existing topologies in a breaking 4.x release later this year, so we strongly encourage our users to try it out as soon as possible.
A call to withTransaction
begins a new transaction, executes the provided function, and then attempts to commit the transaction. The function passed to withTransaction
must take a session
parameter, and this session must be passed to all methods within the function. If some error is encountered, it will attempt to re-commit the transaction before ultimately failing back to the user after aborting the transaction.
NOTE: A mentioned, the passed in function MAY be retried multiple times, please keep this in mind when executing non-database operations within the function.
Here’s an example of it in action:
const client = new MongoClient();
await client.connect();
const session = client.startSession();
// NOTE: the `withTransaction` method only supports functions that return a `Promise`
try {
await session.withTransaction(async function(session) {
const coll = client.db('foo').collection('coll');
await coll.insertOne({ a: 42 }, { session });
});
} catch (err) {
// transaction failed after attempted retry
console.dir({ err });
}
client.connect().then(async function() {
const collection = client.db(‘test’).collection(‘asyncIterators’);
const cursor = collection.find();
for await(const doc of cursor) {
console.log(item);
}
});
find()
.