(nodo: 3341) DeprecationWarning: Mongoose: mpromise


89

Estoy tratando de desarrollar una clase en la parte superior de la mangosta con mis métodos personalizados, así que extendí la mangosta con mi propia clase, pero cuando invoco para crear un nuevo método de automóvil, funciona pero es tira y error, aquí te dejo mira lo que estoy tratando de hacer.

Estoy recibiendo esta advertencia

(node:3341) DeprecationWarning: Mongoose: mpromise (mongoose's default promise library) is deprecated, plug in your own promise library instead: http://mongoosejs.com/docs/promises.html

después de que lo haga

driver.createCar({
      carName: 'jeep',
      availableSeats: 4,
    }, callback);

driver es una instancia de la clase Driver

const carSchema = new Schema({
  carName: String,
  availableSeats: Number,
  createdOn: { type: Date, default: Date.now },
});
const driverSchema = new Schema({
 email: String,
 name: String,
 city: String,
 phoneNumber: String,
 cars: [carSchema],
 userId: {
   type: Schema.Types.ObjectId,
   required: true,
 },
createdOn: { type: Date, default: Date.now },
});
const DriverModel = mongoose.model('Driver', driverSchema);

class Driver extends DriverModel {
  getCurrentDate() {
  return moment().format();
}
create(cb) {
  // save driver
  this.createdOn = this.getCurrentDate();
  this.save(cb);
}
remove(cb) {
  super.remove({
  _id: this._id,
 }, cb);
}
createCar(carData, cb) {
  this.cars.push(carData);
  this.save(cb);
}
getCars() {
  return this.cars;
 }
}

¿Alguna idea sobre lo que estoy haciendo mal?


3
El escritor de Mongoose dice que: "Solo hazlo mongoose.Promise = global.Promisey ya no recibirás esa advertencia". github.com/Automattic/mongoose/issues/…
efkan

Respuestas:


240

Esto es lo que funcionó para aclarar el problema, después de leer los documentos: http://mongoosejs.com/docs/promises.html

El ejemplo en el documento está usando la biblioteca de promesas bluebird, pero elegí ir con promesas nativas de ES6.

En el archivo donde estoy llamando mongoose.connect:

mongoose.Promise = global.Promise;
mongoose.connect('mongodb://10.7.0.3:27107/data/db');

[EDITAR: Gracias a @SylonZero por mencionar un defecto de rendimiento en mi respuesta. Dado que esta respuesta se ve tan bien, siento el deber de hacer esta edición y alentar el uso de bluebirdpromesas nativas en lugar de. Lea la respuesta a continuación para obtener detalles más informados y experimentados. ]


3
Después de verificar el punto de referencia en el sitio web: bluebirdjs.com/docs/benchmarks.html al que se refiere @SylonZero, creo que vale la pena votar su solución en lugar de la primera propuesta. ¡Todavía agradezco a Hunter Lester por este gran trabajo e investigación y por compartir sus hallazgos!
Isak La Fleur

Gracias por su edición que me hace darme cuenta de un gran defecto de rendimiento
Yusuf Kamil AK

71

Si bien la respuesta anterior es precisa y funciona, debe tener en cuenta el problema del rendimiento si tiene una aplicación de nodo de producción real.

La solución anterior utilizará promesas nativas de ES6, que son 4 veces más lentas que bluebird en los puntos de referencia que he compartido a continuación. Esto podría afectar drásticamente el rendimiento de una API escrita en Node y usando MongoDB.

Recomiendo usar Bluebird:

// Assuming you store the library in a var called mongoose
var mongoose = require('mongoose');

// Just add bluebird to your package.json, and then the following line should work
mongoose.Promise = require('bluebird');

Resultados comparativos

Plataforma: (utilizando el último nodo al momento de escribir este artículo)

  • Linux 4.4.0-59-genérico x64
  • Node.JS 6.9.4
  • V8 5.1.281.89
  • CPU Intel (R) Core (TM) i7-6500U a 2,50 GHz × 4
  • 16 GB de RAM con 500 GB de SSD

    | file                                      | time(ms) | memory(MB) |
    |-------------------------------------------|----------|------------|
    | callbacks-baseline.js                     | 114      | 25.09      |
    | callbacks-suguru03-neo-async-waterfall.js | 152      | 32.98      |
    | promises-bluebird-generator.js            | 208      | 29.89      |
    | promises-bluebird.js                      | 223      | 45.47      |
    | promises-cujojs-when.js                   | 320      | 58.11      |
    | promises-then-promise.js                  | 327      | 64.51      |
    | promises-tildeio-rsvp.js                  | 387      | 85.17      |
    | promises-lvivski-davy.js                  | 396      | 81.18      |
    | callbacks-caolan-async-waterfall.js       | 527      | 97.45      |
    | promises-dfilatov-vow.js                  | 593      | 148.30     |
    | promises-calvinmetcalf-lie.js             | 666      | 122.78     |
    | generators-tj-co.js                       | 885      | 121.71     |
    | promises-obvious-kew.js                   | 920      | 216.08     |
    | promises-ecmascript6-native.js            | 931      | 184.90     |
    | promises-medikoo-deferred.js              | 1412     | 158.38     |
    | streamline-generators.js                  | 1695     | 175.84     |
    | observables-Reactive-Extensions-RxJS.js   | 1739     | 218.96     |
    | streamline-callbacks.js                   | 2668     | 248.61     |
    | promises-kriskowal-q.js                   | 9889     | 410.96     |
    | observables-baconjs-bacon.js.js           | 21636    | 799.09     |
    | observables-pozadi-kefir.js               | 51601    | 151.29     |
    | observables-caolan-highland.js            | 134113   | 387.07     |

1
para mi comprensión: ¿de dónde viene su punto de referencia? ¿Existe consenso en torno a estos resultados? Parece que todo el mundo está votando por la respuesta predeterminada de la promesa ES6, pero me gustaría profundizar en los problemas de rendimiento que menciona.
Zedenem

1
El punto de referencia proviene de un conjunto de pruebas que puede leer (y examinar) del repositorio de git de bluebird; las ejecuté de nuevo localmente para obtener los resultados anteriores porque necesitaba los resultados de 2017 para compartir con otros. Más importante aún, he experimentado mejoras en el rendimiento en nuestra propia API (tengo 5 microservicios y un objetivo de escalabilidad difícil) y he tenido que tomar decisiones a menudo para utilizar devoluciones de llamada anidadas simples en lugar de promesas (sigue siendo la más rápida). Personalmente, creo que los puntos de referencia son solo un primer paso hacia una decisión, pero todavía no puedo compartir mis datos internos ... mi objetivo de escala es 10K usuarios por máquina física.
SylonZero

Además, la votación a favor no es una medida completa sobre una respuesta. En mi experiencia, muchos rara vez profundizan después de que se ha resuelto un problema (o leído cualquier otra cosa) y muchos programadores a los que he sido mentor en el pasado necesitaban aprender sobre rendimiento e instrumentación para el código.
SylonZero

Muchas gracias por mencionar los problemas de rendimiento. Soy un programador novato, solo 2 años en eso, y anhelo esta educación. Estoy usando esto en producción, así que estoy aún más contento de saber si es así. ¿Cuáles son las mejores formas de realizar evaluaciones comparativas de programas y fragmentos de código?
Hunter Lester

1
Hunter, eso dependería de la naturaleza de la plataforma y el código, pero relacionado con esta pregunta: hay dos lados para obtener información: 1. buenas pruebas para usar a través de un generador de carga para simular las solicitudes de los usuarios. Utilizo Apache jMeter para probar mi API de nodo y generar carga para múltiples usuarios. 2. Instrumentación: cómo se realiza un seguimiento de las transacciones individuales. Utilizo NewRelic para instrumentar mi código de nodo: brinda un desglose detallado de cada transacción en ms (hasta la ruta Express, el tiempo de consulta de Mongo, Redis para las sesiones, etc.). Espero que esto te ayude a empezar.
SylonZero

2

¿Intentaste esto? Por ejemplo :

const mongoose = require('mongoose')
mongoose.Promise = global.Promise // <--
const Schema = mongoose.Schema
const UserSchema = new Schema({
  name: String,
})
const User = mongoose.model('user', UserSchema)
module.exports = User

si crea un modelo a partir de una instancia de mangosta cuya promesa no se redefinió, cada consulta en este modelo arrojaría la advertencia.


2

Creo que tienes tu respuesta, pero uso global.promise con manejo de errores

// MongoDB connection
mongoose.Promise = global.Promise;

var promise = mongoose.connect('mongodb://localhost:27017/test_db', {
  useMongoClient: true,
});

promise.then(function(db) {
    console.log("Connected to database!!!");
}, function(err){
    console.log("Error in connecting database " + err);
});

1
var mydb;
var uri = 'mongodb://localhost/user1';
var promise = mongooose.connect(uri,{
      useMongoClient: true,
});
promise.openUri(uri,function(errr,db){
if(errr){
        throw errr;
      }else{
        console.log("Connection Successfull");      
        mydb = db;
      }
});

Uno necesita tener conexión con la ayuda de la promesa en la última versión de mangosta [este es el enlace] [1] [1]: http://mongoosejs.com/docs/promises.html



0

Mangosta 4.8.6

Si detecta un error como este:

(nodo: 9600) DeprecationWarning: Mongoose: mpromise (biblioteca de promesas predeterminada de mangosta) está en desuso, conecte su propia biblioteca de promesas en su lugar: http://mongoosejs.com/docs/promises.html

También necesita establecer opciones que prometan la biblioteca que se utilizará para el controlador.

mongoose.Promise = global.Promise
mongoose.connect(uri, { useMongoClient: true, options: { promiseLibrary: mongoose.Promise }})

0
var mongoose = require('mongoose');
mongoose.Promise = global.Promise;
db = mongoose.connect(env.DATABASE_URI, function(){
  //
})

este trabajo para mi.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.