(Knoten: 3341) DeprecationWarning: Mongoose: mpromise


89

Ich versuche, mit meinen benutzerdefinierten Methoden eine Klasse auf dem Mungo zu entwickeln, also habe ich den Mungo um meine eigene Klasse erweitert, aber wenn ich aufrufe, um eine neue Automethode zu erstellen, funktioniert sie, aber ihr Streifen und Fehler, hier lasse ich Sie sehen, was ich versuche zu tun.

Ich bekomme diese Warnung

(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

nachdem ich es tue

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

Treiber ist eine Instanz der Treiberklasse

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;
 }
}

Irgendwelche Gedanken darüber, was ich falsch mache?


3
Der Autor von Mongoose sagt: "Tu es einfach mongoose.Promise = global.Promiseund du solltest diese Warnung nicht mehr bekommen." github.com/Automattic/mongoose/issues/…
efkan

Antworten:


241

Nach dem Lesen der Dokumente konnte ich das Problem wie folgt beheben: http://mongoosejs.com/docs/promises.html

Das Beispiel im Dokument verwendet die Bluebird-Versprechensbibliothek, aber ich habe mich für native ES6-Versprechungen entschieden.

In der Datei, in der ich anrufe mongoose.connect:

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

[EDIT: Vielen Dank an @SylonZero für den Hinweis auf einen Leistungsfehler in meiner Antwort. Da diese Antwort so sehr geschätzt wird, fühle ich mich verpflichtet, diese Änderung vorzunehmen und die Verwendung von bluebirdanstelle von einheimischen Versprechungen zu fördern . Bitte lesen Sie die Antwort unter dieser, um weitere Informationen zu erhalten. ]]


3
Die Benchmark auf der Website nach Überprüfung: bluebirdjs.com/docs/benchmarks.html @SylonZero bezieht sich auf, ich glaube , seine Lösung in wert abstimmen anstelle des ersten Vorschlag. Ich danke Hunter Lester immer noch für diese großartige Arbeit und Untersuchung und den Austausch seiner Ergebnisse!
Isak La Fleur

Vielen Dank für Ihre Bearbeitung, die mich einen großen Leistungsfehler erkennen lässt
Yusuf Kamil AK

70

Obwohl die obige Antwort korrekt ist und funktioniert, müssen Sie das Problem der Leistung berücksichtigen, wenn Sie eine echte Produktionsknoten-App haben.

Die obige Lösung verwendet native ES6-Versprechen, die in den unten angegebenen Benchmarks viermal langsamer sind als Bluebird. Dies kann die Leistung einer in Node geschriebenen API, die MongoDB verwendet, dramatisch beeinträchtigen.

Ich empfehle die Verwendung von 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');

Benchmark-Ergebnisse

Plattform: (unter Verwendung des neuesten Knotens zum Zeitpunkt des Schreibens)

  • Linux 4.4.0-59-generisches x64
  • Node.JS 6.9.4
  • V8 5.1.281.89
  • Intel (R) Core (TM) i7-6500U-CPU bei 2,50 GHz × 4
  • 16 GB RAM mit 500 GB 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
Nach meinem Verständnis: Woher kommt Ihr Benchmark? Gibt es einen Konsens über diese Ergebnisse? Es scheint, als würden alle für die Standard-ES6-Antwort stimmen, aber ich möchte mich eingehender mit den von Ihnen erwähnten Leistungsproblemen befassen.
Zedenem

1
Der Benchmark stammt aus einer Reihe von Tests, die Sie aus dem Bluebird Git Repo lesen (und untersuchen) können. Ich habe sie erneut lokal ausgeführt, um die oben genannten Ergebnisse zu erhalten, da ich die Ergebnisse für 2017 benötigte, um sie mit anderen zu teilen. Noch wichtiger ist, dass ich in unserer eigenen API Leistungssteigerungen verzeichnet habe (ich habe 5 Mikrodienste und ein hartes Skalierbarkeitsziel) und oft Entscheidungen treffen musste, um einfache verschachtelte Rückrufe anstelle von Versprechungen zu verwenden (immer noch die schnellsten). Ich persönlich denke, Benchmarks sind nur ein erster Schritt in Richtung einer Entscheidung, aber ich kann meine internen Daten noch nicht teilen ... mein Skalierungsziel sind 10.000 Benutzer pro physischer Maschine.
SylonZero

Auch das Upvoting ist kaum ein vollständiges Maß für eine Antwort. Nach meiner Erfahrung graben viele selten tief, nachdem ein Problem gelöst wurde (oder etwas anderes gelesen wurde), und viele Programmierer, die ich in der Vergangenheit betreut habe, mussten über Leistung und Instrumentierungsfähigkeiten für Code unterrichtet werden.
SylonZero

Vielen Dank, dass Sie die Leistungsprobleme angesprochen haben. Ich bin ein Anfänger Programmierer, nur 2 Jahre, und sehne mich nach dieser Ausbildung. Ich benutze dies in der Produktion, deshalb bin ich umso mehr froh zu wissen, ob es so ist. Was sind die besten Möglichkeiten, um Programme und Codeteile zu vergleichen?
Hunter Lester

1
Hunter, das würde von der Art der Plattform und dem Code abhängen, aber mit dieser Frage zusammenhängen: Es gibt zwei Seiten, um Einblicke zu erhalten: 1. Gute Tests, die über einen Lastgenerator verwendet werden können, um Benutzeranforderungen zu simulieren. Ich verwende Apache jMeter, um meine Knoten-API zu testen und eine Last für mehrere Benutzer zu generieren. 2. Instrumentierung: Wie verfolgen Sie die einzelnen Transaktionen? Ich verwende NewRelic, um meinen Knotencode zu instrumentieren - es gibt eine detaillierte Aufschlüsselung jeder Transaktion in ms (bis auf die Express-Route, Mongo-Abfragezeit, Redis für Sitzungen usw.). Ich hoffe, das bringt Sie zum Laufen.
SylonZero

2

hast du das versucht Zum Beispiel :

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

Wenn Sie ein Modell aus einer Mungo-Instanz erstellen, deren Versprechen nicht neu definiert wurde, wird bei jeder Abfrage in diesem Modell die Warnung ausgegeben.


2

Ich denke, Sie haben Ihre Antwort, aber ich verwende global.promise bei der Fehlerbehandlung

// 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;
      }
});

Man muss eine Verbindung mit Hilfe von Versprechen in der neuesten Version von Mungo haben [dies ist der Link] [1] [1]: http://mongoosejs.com/docs/promises.html



0

Mungo 4.8.6

Wenn Sie Fehler wie diesen abfangen:

(Knoten: 9600) DeprecationWarning: Mongoose: mpromise (die Standardversprechenbibliothek von mongoose) ist veraltet. Schließen Sie stattdessen Ihre eigene Versprechenbibliothek an: http://mongoosejs.com/docs/promises.html

Sie müssen auch Optionen festlegen, die die Verwendung der Bibliothek für den Treiber versprechen.

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(){
  //
})

diese Arbeit für mich.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.