I use Node with Monk, a simple library for MongoDB. It doesn't have insertOne and so on. And it's totally annoying to get a deprecation warning on each insert. Does MongoDB have an option to disable deprecation warnings?
(node:17737) DeprecationWarning: collection.insert is deprecated. Use insertOne, insertMany or bulkWrite instead.
You didn't add your node code (and lots of time has passed) but for future answer searchers - some mongoose methods can receive a SaveOptions object.
ie. when using collection.save you can pass this in like so:
doc.save({ suppressWarning: true })
If possible - it's better to "fix" the warnings by moving on from the deprecated apis to the recommended ones.
Related
I am following a guide on Node.js and Mongoose. Developing some code for an eCommerce store. I have two code snippets, both use populate() on a Model however one code snippet requires execPopulate() to return a promise but the other doesn't. I have tried removing execPopulate and adding it to the other method but I get errors on both.
Any explanation is welcomed and appreciated. Thank you!
Populate() return «Query» this see here and according to mongoose docs again Query is not a promise.
Mongoose queries are not promises. They have a .then() function for co and async/await as a convenience. However, unlike promises, calling a query's .then() can execute the query multiple times.
So if you want to use populate as a promise use execPopulate()
We are migrating from ExpressJS 3 to ExpressJS 4, and we noted that the following APIs are being deprecated:
req.param(fieldName)
req.param(fieldName, defaultValue)
Is there a middleware that brings these APIs back, like other APIs that were 'externalized' from express to independent modules ?
EDITED:
Clarification - The need is an API that provides an abstracted generic access to a parameter, regardless to if it is a path-parameter, a query-string parameter, or a body field.
Based on Express Documentation, we should use like this
On express 3
req.param(fieldName)
On express 4
req.params.fieldName
Personally i prefer req.params.fieldName instead req.param(fieldName)
Why would you want to bring it back? There's a reason that it's been deprecated and as such you should probably move away from it.
The discussion on why they are deprecating the API is available at their issue tracker as #2440.
The function is a quick and dirty way to get a parameter value from either req.params, req.body or req.query. This could of course cause trouble in some cases, which is why they are removing it. See the function for yourself here.
If you are just using the function for url parameters, you can just replace it with this a check for req.query['smth'] or 'default':
var param_old = req.param('test', 'default');
var param_new = req.query['test'] || 'default';
(Please note that an empty string is evaluated to false, so they are not actually 100% equal. What you want is of course up to you, but for the most part it shouldn't matter.)
Ok, after reading the threads given in references by #Ineentho, we decided to come up with the following answer:
https://github.com/osher/request-param
A connect/express middleware to enable back the req.param(name,default) API deprecated in express 4
The middleware does not only brings back the goo'old functionality.
It also lets you customize the order of collections from which params are retrieved , both as default rule, and as per-call :-)
Have fun!
I know how to handle specific errors in promises but I sometimes have pieces of code that looks like this:
somePromise.then(function(response){
otherAPI(JSON.parse(response));
});
Sometimes, I get invalid JSON which causes a silent failure here when JSON.parse throws. In general I have to remember to add a .catch handler to every single promise in my code and when I don't I have no way to find out where I forgot one.
How do I find these suppressed errors in my code?
Edit
We've finally fixed this in Node.js 15, it took 5 years but native promise rejections now behave like uncaught exceptions - so it's fine to just add a process.on('uncaughtException' handler.
In Modern Node.js
Starting with io.js 1.4 and Node 4.0.0 you can use the process "unhandledRejection" event:
process.on("unhandledRejection", function(reason, p){
console.log("Unhandled", reason, p); // log all your errors, "unsuppressing" them.
throw reason; // optional, in case you want to treat these as errors
});
This puts an end to unhandled rejections problems and the difficulty of tracking them down in your code.
In Older NodeJS
These events were not yet back-ported to older versions of NodeJS and are unlikely to be. You can use a promise library that extends the native promise API such as bluebird which will fire the same events as there are in modern versions.
It's also worth mentioning that there are several userland promise libraries that offer the unhandled rejection detection facilities and much more such as bluebird (which also has warnings) and when.
I'm using collection.insert then in the callback collection.findAndModify
About 10% of the time collection.findAndModify fails to find the document I just inserted, even though it's being executed after the insert callback. Why is this possible? How do I deal with that?
I insert it, then try to modify it, but it's not there, then try to modify it again and it's there.
You should give the second command in the callback as the insert is asynchronous. If you are using the mongodb native driver for node,
collection.insert(document, function(err, records){
//call collection.findAndModify here
});
Check the docs
I'm using IcedCoffeeScript.
I want to write this:
User.find(id).always esc done or await User.find(id).always defer e, user
But Promise#always is deprecated in when.js.
Is there another way?
Promise#always is deprecated in when.js and will be removed in an upcoming version.
However, promise.always(onFulfilledOrRejected, onProgress) is nothing but a shortcut for .then(onFulfilledOrRejected, onFulfilledOrRejected, onProgress). So instead of using
.always(handler)
You will have to use
.then(handler, handler)
If may affect your code if you were using inline functions for .always as with .then it would be better to extract them as separate functions.
Authors of when.js recommend using promise.ensure instead of promise.always. More details here.
promise.ensure is safer in that it cannot transform a failure into a success by accident (which always could do simply by returning successfully!).
I hope that will help.