Mongoose: OverwriteModelError mit Mokka 'Uhr'

Erstellt am 14. Dez. 2012  ·  61Kommentare  ·  Quelle: Automattic/mongoose

Ich habe gerade von 3.4.0 auf 3.5.1 aktualisiert, und wenn ich Mocha-Tests an einem Modell 'beobachte', erhalte ich jedes Mal, wenn die Datei neu geladen wird, einen OverwriteModelError, weil ich das Modell erneut 'erfordere' - und ich schätze, neu zu definieren -.

Es muss einen gewissen Wert haben, einen Fehler "überschreiben" zu machen, aber ich gehe vorerst auf 3.4.0 zurück, weil dies zu mühsam ist.

Hilfreichster Kommentar

Es gibt eine andere Möglichkeit: Mungo von allen Modellen und Schemata zu reinigen.
In meinem Testcode habe ich Folgendes hinzugefügt:

 mongoose.models = {};
 mongoose.modelSchemas = {};

Und es funktioniert gut, zumindest bei mir.

Alle 61 Kommentare

Dies wird durch einen Programmierfehler verursacht. Der mehrmalige Aufruf von mongoose.model() oder connection.model() mit demselben Namen und Schema führt nicht zu einem Fehler. Die Übergabe des Namens eines Modells, das mit einem anderen Schema vorhanden ist, führt zu dem Fehler. Das Überschreiben von Modellen war eigentlich nie erlaubt.

Wenn die Mokka-Uhr Ihr Schema erneut erfordert und mongoose.model(preExistingName, newSchema) aufruft, dann erhalten Sie jetzt eine Fehlermeldung. Zuvor hat Mungo in diesem Szenario überhaupt kein neues Modell kompiliert, sondern nur den Programmierfehler geschluckt und das alte Modell zurückgegeben, was ein falsches Verhalten ist.

var schema = new Schema;
var A = mongoose.model('A', schema);
var B = mongoose.model('A', schema); // no error
var C = mongoose.model('A', new Schema); // previously unreported error

Okay, das macht Sinn. Vielen Dank!

@aheckmann - ich --watch und ich bekomme

OverwriteModelError: Cannot overwrite "User" model once compiled.

user.js

var mongoose = require('mongoose'),
  Schema = mongoose.Schema,
  ObjectId = mongoose.SchemaTypes.ObjectId;

var userSchema = new Schema({
  name: { type: String }
}), 
  User;

// other virtual / static methods added to schema

User = mongoose.model('User', userSchema);
module.exports = User;

userSpec.js

var User = require('../models/user'),
  mongoose = require('mongoose');

mongoose.connection.on('error', function (err) {
  console.log(err);
}

mongoose.connection.on('open', function () {
  console.log('connected');
}

describe('User', function () {

  before(function (done) {
    mongoose.connect('mongodb://localhost/test');
    done();
  }

  after(function (done) {
    mongoose.disconnect(function () {
      console.log('disconnected');
      done();
    });
  });

  it('should test something', function (done) {
     // tests
     done();
  });
});

Für Mungos-Tests erstellen wir einfach jedes Mal neue Verbindungen und es funktioniert gut.

var db = mongoose.createConnection()

https://github.com/LearnBoost/mongoose/blob/master/test/common.js#L74 -L98

Das sehe ich auch. Hier ein Minimalbeispiel:

https://github.com/j0ni/mongoose-strangeness

Vielleicht fehlt mir die richtige Definition von Modellen...?

https://github.com/j0ni/mongoose-strangeness/blob/master/test.spec.js#L21

sollte var Example = connection.model('Example', ExampleSchema)

Danke @aheckmann das funktioniert

es funktioniert b/ca für jeden Ihrer Tests wird eine neue Verbindung erstellt und das Modell wird für jeden lokal innerhalb der Verbindung zwischengespeichert. der andere Weg schlägt fehl, b/c-Modelle wurden für jeden Test auf Mungo-Modulebene kompiliert, daher die Konflikte.

@aheckmann - Ich Lokomotive- App zu testen.

Grundsätzlich bootet jede Testdatei die Locomotive-App in der Funktion before() . Beim Booten der App wird eine Mongo-DB-Verbindung erstellt und in allen meinen Modellen geladen - dies befindet sich in meiner Mongoose-Initialisierungsdatei (wird einmal beim App-Start ausgeführt):

var mongoose = require("mongoose"),
    fs = require("fs");

module.exports = function() {

  // Connect to DB
  switch (this.env) {
    case 'development':
      mongoose.connect('mongodb://localhost/slipfeed');
      break;
    case 'test':
      mongoose.connect('mongodb://localhost/slipfeed');
      break;
    case 'production':
      mongoose.connect('mongodb://mongodb.example.com/prod');
      break;
  }

  // Load models  
  var app = this,
      modelPath = app.get('models');
  fs.readdirSync(modelPath).forEach(function(file) {
    var name = file.substr(0, file.lastIndexOf('.'));
    require(modelPath + '/' + name)(mongoose, app);
  });

}

In jeder meiner Modelldateien mache ich im Grunde Folgendes:

module.exports = function(mongoose, app) {
  var Schema = mongoose.Schema;
  var User = new Schema(...);
  app.User = mongoose.model('User', User);
});

Und in jeder meiner Modelltestdateien mache ich so etwas:

var locomotive = require("locomotive"),
    app = new locomotive.Locomotive(),
    should = require("should");

describe( "User", function() {

  before( function (done) {
    app.boot( process.cwd(), 'test', function () {
      done();
    });
  });

  after( function (done) {
    mongoose.disconnect( function (err) {
      if (err) throw err;
      console.log('DISCONNECT')
      done();
    })
  });      

  ...tests go here

});

Der app.boot() Teil startet nur den Server, lädt die Konfigurationsdatei und durchläuft Initialisierer (das sind nur Dateien, die verschiedene Codeteile enthalten, zum Beispiel das Starten von DB-Verbindungen).

Aber nachdem meine erste Testdatei fertig ist und mocha versucht, die nächste Datei zu laden, bekomme ich OverwriteModelError .

Ich verstehe, dass es wahrscheinlich etwas damit zu tun hat, dass Verbindungen beim Laden der nächsten Testdatei nicht geschlossen werden, oder dass ich meine Modelle möglicherweise falsch initialisiere.

Jedenfalls habe ich versucht, mongoose.disconnect zu meinen after() Funktionen hinzuzufügen, aber das hat nicht geholfen.

es hat nichts mit offenen oder geschlossenen Verbindungen zu tun. Sie versuchen, ein bereits vorhandenes Modell in ein anderes Schema umzudefinieren.

var a = new Schema({ x: 'string' });
var b = new Schema({ x: 'string' });
mongoose.model('Thingy', a);
mongoose.model('Thingy', a); // ok, a === the registered schema instance
mongoose.model('Thingy', b); // error a !== the registered schema

FWIW, ich denke, ein etwas weniger trivialer Beispielcode würde verhindern, dass dies wiederholt auftaucht. Vielleicht initialisiert eine winzige Express-App, die ein einzelnes Modell definiert, die Verbindung auf eine injizierbare Weise und ein Mokka-Integrationstest (in meinem Fall verwende ich Supertest, aber was auch immer), der die Verbindung injiziert, ohne dieses Problem auszulösen.

Wenn es eine App gibt, die Sie von @aheckmann kennen , die wir uns Zweck erfüllen .

Hier ist, worauf ich zurückgegriffen habe:

https://github.com/j0ni/beachenergy.ca/blob/master/datamodel/index.js

Ich mag es nicht, aber es löst das Problem. Wenn ich ein Mungo-Anti-Muster verwende (scheint wahrscheinlich), würde ein kanonisches Beispiel helfen.

Hallo @aheckmann - Ich bin mir 100% sicher, dass ich kein neues Modell mit einem anderen Schema erstelle. Ich habe ein Skelett / Demo-Projekt erstellt, um dieses Problem zu veranschaulichen: https://github.com/davisford/mongoose-test

Beginnen Sie Mokka mit make und beim ersten Durchlauf werden die Tests bestanden. Bearbeiten Sie nun models/user.js und speichern Sie (zB STRG/CMD + S), und mocha nimmt die Änderung mit --watch und wir drücken OverwriteModelError .

Hier ist eine weitere Option... Ich verwende nodemon. Dadurch wird sichergestellt, dass der Prozess bei jedem Testlauf neu gestartet wird:
$ nodemon --exec "mocha -R min" test

Was ist also die empfohlene Lösung dafür? Vor jedem Test eine neue Verbindung erstellen? Wie sonst können wir ein Mongoose-Modell in unseren Spezifikationen definieren und beim Anschauen keinen Fehler haben?

Ich habe es aufgegeben, es allein mit Mokka zu lösen. Stattdessen betreibe ich Mocha über Nodemon. Auf diese Weise wird der Knotenprozess neu gestartet und das Problem behoben.

Petter Graff
(von meinem iPad gesendet, Rechtschreibfehler wahrscheinlich :)
+1.512.784.3232
peter. [email protected]

Am 2. Februar 2013 um 5:41 Uhr schrieb Oliver Joseph Ash [email protected] :

Was ist also die empfohlene Lösung dafür? Vor jedem Test eine neue Verbindung erstellen? Wie sonst können wir ein Mongoose-Modell in unseren Spezifikationen definieren und beim Anschauen keinen Fehler haben?


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Wie läuft Mocha über Nodemon genau? Ich habe es versucht, aber ich bin wahrscheinlich weit davon entfernt:

nodemon /usr/local/share/npm/bin/mocha --reporter spec --ui bdd --watch ./server/test/*.js

Ich benutze:
nodemon --exec "mocha -R min" test

In dem Beispiel, das Sie unten zeigen, verwenden Sie anscheinend eher spec als min und haben Ihre Tests in server/test ... Wenn ja, ändern Sie einfach die Parameter ...

Am 2. Februar 2013 um 7:00 Uhr schrieb Oliver Joseph Ash [email protected] :

Wie läuft Mocha über Nodemon genau? Ich habe es versucht, aber ich bin wahrscheinlich weit davon entfernt:

nodemon /usr/local/share/npm/bin/mocha --reporter spec --ui bdd --watch ./server/test/*.js

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Schön. Nicht ganz so schnell wie --watch , aber was noch wichtiger ist, es funktioniert.

Mir ist auch aufgefallen, dass Mocha sie nicht neu lädt, wenn Änderungen am Schema vorgenommen werden, die der Mocha-Test erfordert, da sie zwischengespeichert werden :(

Am 2. Februar 2013 um 15:23 Uhr schrieb Petter Graff [email protected] :

Ich benutze:
nodemon --exec "mocha -R min" test

In dem Beispiel, das Sie unten zeigen, verwenden Sie anscheinend eher spec als min und haben Ihre Tests in server/test ... Wenn ja, ändern Sie einfach die Parameter ...

Am 2. Februar 2013 um 7:00 Uhr schrieb Oliver Joseph Ash [email protected] :

Wie läuft Mocha über Nodemon genau? Ich habe es versucht, aber ich bin wahrscheinlich weit davon entfernt:

nodemon /usr/local/share/npm/bin/mocha --reporter spec --ui bdd --watch ./server/test/*.js

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.


Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Die Lösung von @j0ni hat bei mir gut funktioniert. Am Ende ersetzte ich alle Aufrufe von "mongoose.model" durch:

try {
    // Throws an error if "Name" hasn't been registered
    mongoose.model("Name")
} catch (e) {
    mongoose.model("Name", Schema)
}

Ich stimme zu, dass es nicht schön ist, seinen Code mit solchen Anrufen zu vermüllen. Es wäre schön, eine Abkürzung dafür zu haben, die für den häufigsten Fall funktioniert, nämlich dass ein Modul einfach zur Laufzeit neu geparst wird, ohne das Schema zu ändern. Nennen Sie es vielleicht so etwas wie ein mongoose.getOrCreate(name, schema) .

@yourcelf hat Ihren Vorschlag angenommen und für mich gearbeitet. Vielen Dank.

module.exports = getOrCreateModel('User', UserSchema);

Es gibt eine andere Möglichkeit: Mungo von allen Modellen und Schemata zu reinigen.
In meinem Testcode habe ich Folgendes hinzugefügt:

 mongoose.models = {};
 mongoose.modelSchemas = {};

Und es funktioniert gut, zumindest bei mir.

@remicastaing Perfekt, funktioniert bei mir. Vielen Dank!

@remicastaing bisher beste

@remicastaing Hat bei mir auch funktioniert, scheint bisher die beste Lösung zu sein

@remicastaing ja, sieht nach einer funktionierenden Lösung aus.

Es weiß aber immer noch nicht, was das eigentliche Problem ist.

@remicastaing Danke, funktioniert bei mir auch!

@remicastaing Arbeitet auch für mich. Danke.

Es tut mir leid, einen alten Juckreiz zu kratzen, aber ich stehe vor dem gleichen Problem, wenn ich versuche, mocha -w mit Mungo auszuführen, habe jede mögliche Lösung ausprobiert, aber jetzt stoße ich gegen die Wand.

wo soll ich hinstellen

 mongoose.models = {};
 mongoose.modelSchemas = {};

?

vorherJeder, nachherJeder, nachher, vorher ?

Sollte ich mongoose.createConnection() auf beforeEach, schließen auf afterEach?

Ich lege die

mongoose.models = {};
mongoose.modelSchemas = {};

gleich nach

var mongoose = require('mongoose');

in einer config.test.js Datei direkt im test Ordner ( config.test.js die einzige *.test.js Datei im Testordner, andere *.test.js Dateien sind in Unterordner). Wenn Mokka rekursiv ( --recursive Option in mocha.opts ) durch den Testordner geht, beginnt es mit config.test.js .

@remicastaing danke! Arbeite auch für mich (Jasmin)

Nur ein anderer Fall:
Ich hatte dieses Problem, als ich ein Modell mit unterschiedlichen Großbuchstaben im Code und im Test benötigte.
Zum Beispiel in der Spezifikation:
var User = require('./models/user');
und im Code
var User = require('./models/User');
Denken Sie nur daran, dass es keine zwischengespeicherte Version für verschiedene Eingaben gab

+1 zu dem, was @asci erlebt hat. Wenn Sie dasselbe Modell benötigen, jedoch mit einem anderen Gehäuse in zwei verschiedenen Dateien und diese dann in einer anderen benötigen, wird der Fehler "Kann nicht überschreiben" ausgegeben

@iandoe Ich benutze mongoose.connect und mache den Mokka-Test

after(function(done){
  mongoose.models = {};
  mongoose.modelSchemas = {};
  mongoose.connection.close();
  done();
});

:+1: :Bogen:

:+1:

Wenn Sie ein Modell in beforeEach erstellen möchten, erstellen Sie eine neue Verbindung mit var db = mongoose.createConnection(); und dann db.model(...) im Gegensatz zu mongoose.model(...); in beforeEach . Dieses Verhalten ist eher beabsichtigt als ein Fehler.

Ich habe Code, der zur Laufzeit neu geladen werden kann, daher möchte ich ein vorhandenes Modell überschreiben, wenn ich während der Entwicklung das Schema oder die Modellfunktionen ändere.

Es sei denn, es gibt einen guten Grund, es nicht zu tun, ich sehe nicht, warum ich so etwas nicht tun sollte.

Beispiel

delete mongoose.models['somemodel'];
var somemodel = db.mongoose.model('somemodel', someschema);

Das funktioniert für mich, ich mache das seit ungefähr einem Jahr so.

Oder vielleicht gibt es eine Möglichkeit, das Schema und die Modellfunktionen zu ändern, ohne ein vorhandenes Modell / Schema zu löschen, aber ich habe mich nicht die Mühe gemacht, weiter zu untersuchen.

:+1:

Ich weiß, dass dies alt ist, aber wenn jemand darüber stolpert, habe ich es gelöst, indem ich eine Datenbanktestdienstprogrammdatei wie diese erstellt habe:

// DatabaseUtils.js
import mongoose from 'mongoose';
const MONGO_URI = 'mongodb://localhost:27017/collectionname'

export function tearDown(){
  mongoose.models = {};
  mongoose.modelSchemas = {};
  resetDb();
  if(mongoose.connection.readyState) mongoose.disconnect();
}

export function setUp(){
  if(!mongoose.connection.readyState) mongoose.connect(MONGO_URI);
}

export function resetDb(){
  if(mongoose.connection.db) mongoose.connection.db.dropDatabase();
}

Dann können Sie aus Ihrer Testdatei Folgendes verwenden:

import { setUp, tearDown, resetDb } from './DatabaseUtils'

describe('Testing MongoDB models', function(){
  before(setUp)
  after(tearDown)
  afterEach(resetDb)

  it('Some test of a mongoose model', () =>  {
  // Test code here.
  }
})

Diese StackOverflow-Antwort löst es wie

let users
try { users = mongoose.model('users') }
catch (e) { users = mongoose.model('users', <UsersSchema...>) }

Bearbeiten: Wie von @DanielRamosAcosta hervorgehoben , "Das Problem ist, dass Änderungen nicht wirksam werden, wenn sich Ihr Schema ändert."

Danke @remicastaing , ich habe 5 Minuten verloren, bis ich deine Lösung erreicht habe, sollte offensichtlicher sein :)

Danke @juanpabloaj , das hat bei mir funktioniert

@gunar Das Problem ist, dass Änderungen nicht wirksam werden, wenn sich Ihr Schema ändert.

@juanpabloaj Danke Bruder!

Ich benutze einfach, anstatt einen hässlichen try/catch zu erstellen:

let users = mongoose.models.users || mongoose.model('users', <UsersSchema...>)

Diese Diskussion ist wirklich beschämend
Die eigentlichen Autoren von Mungo gaben die richtige Lösung ( 1 und 2 ), aber alle Daumen hoch gehen auf falsche Hacky-Lösungen.
Wirklich beschämend

@tomyam1 , vielleicht weil diese Hacky-Lösungen unsere Probleme ohne Probleme lösen... :smiley:

Manchmal funktioniert eine bequeme Lösung besser als eine technisch korrekte :)

@tomyam1 Es ist nicht beschämend, bei der Lösung eines Problems zusammenzuarbeiten, und ich bin jedem dankbar, der hier seine eigene Meinung zu einer Lösung gepostet hat. Ohne ins Detail zu gehen - in meinem Fall hat einer der "falschen Hacky"-Vorschläge perfekt funktioniert, und beide, die Sie als "richtige" Lösungen bezeichnen, haben nicht funktioniert.

Sich gegenseitig zu helfen ist keine Schande. Danke an alle die einen konstruktiven Beitrag geschrieben haben.

Nun, meine Herren (garethdown44, fega), dann sind wir uns nicht einig.
Um zu vermeiden, dass noch mehr Spam erzeugt wird, verwenden Sie bitte die Emojis-Reaktionen.

Um diesen Thread zusammenzufassen:

Auf dieser Seite gibt es nur drei verschiedene Lösungen:

  1. Zwischengespeichertes Modell verwenden, falls vorhanden:
mongoose.models.users || mongoose.model('users', <UsersSchema...>)

oder

try {
    // Throws an error if "Name" hasn't been registered
    mongoose.model("Name")
} catch (e) {
    mongoose.model("Name", Schema)
}

Dies ist keine Lösung, da Änderungen in den Modellen nicht übernommen werden.

  1. Löschen Sie den Modellcache
 mongoose.models = {};
 mongoose.modelSchemas = {};

Habe diese Lösung ausprobiert und sie hat nicht funktioniert, und wer weiß warum?
Es beruht auf der Änderung undokumentierter interner Variablen.
Es hat wahrscheinlich funktioniert, als es 2013 vorgeschlagen wurde, aber es ist 4 Jahre später.

  1. Speichern Sie das Modell auf der Verbindung.
    Dies ist die offizielle Lösung, die von den Autoren von mogoose vorgeschlagen wurde.
    Und doch wurde es fast komplett übersehen. Für mich ist das beschämend.
const Mongoose = require('mongoose');
const DB = Mongoose.createConnection(...);
const Model = DB.model("Name", schema);

@tomyam1 -

In meinem Fall habe ich mich für die Nodemon-Lösung entschieden. Als mir klar wurde, was passierte und wie der Testcode strukturiert war, hätte es eine große Umgestaltung erfordert, für die ich keine Zeit habe. Ich bin froh, dass die Nodemon-Lösung vorgeschlagen wurde und die Leute ihr +1 gegeben haben. Das ist alles, was ich sage.

Leider startet Nodemon die gesamte Testsuite neu. mocha --watch hat viel schnelleres Nachladen

Leider startet Nodemon die gesamte Testsuite neu, daher hat Mokka --watch viel schnelleres Nachladen

Ein langsames Neuladen und ein vernünftiger Entwickler ist ein Kompromiss, den ich über das Schneiden von Millisekunden (oder Sekunden) aus einem Testlauf mache.

Außerdem, wie hier nicht erwähnt, ist npm-watch ein Werkzeug dafür (es umschließt Nodemon), sodass Sie ein einfaches npm-Skript watch https://www.npmjs definieren können. com/Paket/npm-watch

Ich hatte das gleiche Problem, also überprüfe ich mongoose.modelNames() und bestimme, ob ich das Modell kompiliere oder nur das bereits kompilierte Modell abrufe, da mocha --watch dieses Problem verursacht. Also hier ist der Code:

mongoose.modelNames().indexOf("User") === -1 //if my model has not been compiled...
 ? mongoose.model("User", UserSchema) //...compile model and return it
 : mongoose.connection.model("User"); //else it is already compiled, so return this model

Jetzt geben Sie dies als Funktion zurück (ersetzen Sie "User" durch das Argument und UserSchema durch das Argument für Ihr Schema) für module.exports und rufen Sie diese Funktion bei Bedarf auf.

https://stackoverflow.com/a/49806603/5674976

@remicastaing funktioniert wie ein Zauber, danke!

Bei einigen speziellen Instanzierungen kann es erforderlich sein, die models Referenzen zu löschen

after((done) => {
  Object.keys(mongoose.models).forEach((k) => {
    delete mongoose.models[k];
  });
  Object.keys(mongoose.modelSchemas).forEach((k) => {
    delete mongoose.modelSchemas[k];
  });
  mongoose.connection.close();
  done();
});

mocha --watch benötigt nichts außerhalb von describe , dh definiert Ihre Schemas nicht neu.

Die effizienteste, eleganteste und verständlichste Testmethode, die die geringste Anzahl von Verbindungen zur Datenbank herstellt, besteht darin, Ihre Verbindung, Schemata und Modelle außerhalb Ihrer Testsuite einzurichten.

Dieser Code ist im Vergleich zu meinem anderen Beispiel zum Einrichten eines Modells vor jedem Test sehr trocken (für mich nicht erforderlich).

Die folgende Testsuite funktioniert:

const expect = require("chai").expect;
const mongoose = require("mongoose"),
  UserSchema = require("../data/models/User");
const connection = mongoose.createConnection(
  process.env.MONGO_URL || "mongodb://127.0.0.1/test"
);
const User = connection.model("User", UserSchema);

describe("Database Testing", function() {
  it("MongoDB is working and repeatedly testable", function(done) {
    let user = User({
      username: "My user"
    });

    user
      .save()
      .then(doc => {
        console.log(doc); // This outputs the doc.
        expect(doc.username).to.equal("My user");
        done();
      })
      .catch(err => {
        console.error(err);
        expect(err).to.be.null;
        done();
      });
  });
});

Ab ../data/models/User.js

let mongoose = require("mongoose");

let UserSchema = new mongoose.Schema({
  username: String
});
module.exports = UserSchema; // 

Früher war ich verwirrt darüber, wie MongoDb seine Verbindungen, Schemata und Modelle herstellte. Mir war nicht klar, dass man ein Modell definieren und viele Male verwenden kann (obv. aber...)

Ich habe die Dokumentation genau befolgt und ein Modul erstellt, das das Schema definiert und ein Modell zurückgegeben hat.

Dies bedeutete, dass das Schema, wenn ich es in einem Test benötigte, viele Male neu definiert werden würde, da es immer wieder das Modul benötigt, das das Schema definiert. Und mehrfache Definitionen des Schemas sind kein Glück.

People's Lösungen (die funktionieren, wenn auch weniger effizient) lassen Sie vor jedem Test eine neue Verbindung erstellen und oft vor jedem Test ein neues Modell.

Aber ein einfaches Verständnis, dass:

  • mocha --watch führt nichts außerhalb von describe mehr als einmal aus
  • Sie können dieselbe Verbindung, dasselbe Schema und dasselbe Modell mehrmals für verschiedene Dinge verwenden.

hat dies effizient und elegant gelöst.

Unten ist mein weniger effizienter, origineller Weg, um dies zum Laufen zu bringen.

./test/db.spec.js

const expect = require("chai").expect;
const mongoose = require("mongoose"),

  // mocha --watch does not rerequire anything
  // outside of the test suite ("describe").
  // Define your Schemas and models separately, so
  // that you can define your Schema once above
  // your test suites, and your models many times
  // when testing. 
  UserSchema = require("../data/models/User");

describe("mongoose strangeness", function() {
  var connection = mongoose.createConnection(
    process.env.MONGO_URL || "mongodb://127.0.0.1/test"
  );

  // I tried the beforeEach and afterEach, but this wasn't needed:

  // beforeEach(function(done) {
  //   connection = mongoose.createConnection(
  //     process.env.MONGO_URL || "mongodb://127.0.0.1/test"
  //   );
  //   connection.once("open", function() {
  //     done();
  //   });
  // });

  // afterEach(function(done) {
  //   connection.close(function() {
  //     done();
  //   });
  // });

  it("MongoDB testable", function(done) {
    let User = connection.model("User", UserSchema);

    let user = User({
      username: "My user"
    });

    user
      .save()
      .then(doc => {
        console.log(doc); // This outputs the doc every time.
        expect(doc.username).to.equal("My user");
        done();
      })
      .catch(err => {
        console.error(err);
        expect(err).to.be.null;
        done();
      });
  });
});

Fröhliches MongoDbing.

Dieser Code funktioniert bei mir:

if (mongoose.modelNames().includes('Model')) {
    mongoose.deleteModel('Model');
}

mongoose.model('Model', new mongoose.Schema({ ... }));

@verheyenkoen hat recht. Hier ist der Link zu den deleteModel-Dokumenten: https://mongoosejs.com/docs/api/connection.html#connection_Connection -deleteModel

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

ghost picture ghost  ·  3Kommentare

gustavomanolo picture gustavomanolo  ·  3Kommentare

simonxca picture simonxca  ·  3Kommentare

tarun1793 picture tarun1793  ·  3Kommentare

adamreisnz picture adamreisnz  ·  3Kommentare