One of the great perks of living in the San Francisco Bay Area is proximity to some amazing wine regions. Over the last couple years, I've visited vineyards in regions like Napa Valley, Sonoma Valley, Paso Robles, and even Malibu. I recently ran into a machine learning data set that has data on 6000 Portuguese wines that includes a 1-10 quality rating, which seems like a great excuse to build a neural network that can predict the 1-10 quality rating based on factors like residual sugar and alcohol content. Effectively, this neural network attempts to match the wine palate of whoever put this data set together.
Promise.prototype.finally() recently reached stage 4 of the TC39 proposal process. This means the
Promise.prototype.finally() proposal was accepted and is now part of the latest draft of the ECMAScript spec, and it is only a matter of time before it lands in Node.js. This article will show you how to use
Promise.prototype.finally() and how to write your own simplified polyfill.
MongoDB 3.2 introduced the
$lookup aggregation framework pipeline stage, which let you pull documents from a separate collection into your aggregation framework pipeline. Before MongoDB 3.6,
$lookup could only do left outer joins with equality matching. In other words, suppose you had a collection of users, a collection of stocks, and a collection that mapped users to the stocks they hold. The
$lookup stage can give you an array of stocks a user holds. But in MongoDB 3.2 and 3.4,
$lookup could not give you just the stocks that had gone up in price since the customer bought them.
Before MongoDB 3.6, tailing the MongoDB oplog was the only way to listen for changes to your MongoDB database. The oplog is a special collection that logs all inserts and updates that come in to your MongoDB server so other members of the replica set can copy them. Tools like Meteor and MoSQL were built on tailing the oplog. Unfortunately, the oplog was built primarily to support replication internally as opposed to being a user-facing feature. Change streams are a usability layer on top of the MongoDB oplog that make change detection in MongoDB much easier than tailing the oplog directly.
Strong support for arrays has always been one of MongoDB's killer features. For example, suppose you have a collection of blog posts where each document contains an array of comments as shown below. Before MongoDB 3.6, you could only update at most one element of the
comments array at a time because of limitations with the positional operator
$. Array filters in MongoDB 3.6 remove that limitation and add several more exciting features, like updating nested arrays.
One of the major reasons for the mongoose 5 release was the MongoDB driver removing support for the
authenticate() function. Up until Mongoose 4.11, that function was the only way mongoose supported doing authentication. In Mongoose 4.11.0, we added the annoying but necessary
useMongoClient deprecation warning, and in mongoose 5.0.0-rc0 we deleted 686 lines of legacy connection logic that removed the need for the
useMongoClient option. In addition, we made a couple related improvements to the connection API that will make mongoose much cleaner to work with: we made
mongoose.connect() always return a promise, and we added a global and connection-level
Mongoose 5.0.0-rc0 introduced several important changes to the way middleware works. The most pronounced difference is the ability to use promises and async/await with mongoose middleware. In addition, there are a couple more subtle changes that make the middleware API more consistent. In this article, I'll cover two changes. The first is that post hooks now always get flow control, even synchronous post hooks. The second is that query middleware is applied when the model is compiled for performance reasons.