Dies wird Ihr Problem nicht lösen, aber es sollte Sie in die richtige Richtung weisen und es Ihnen vielleicht ermöglichen, das Problem zu isolieren, das Sie verwenden können, um eine neue Frage zu erstellen:
Gibt es nicht. Es gibt nur einen Index, und er hat einen Namen und einen Schlüsseldeskriptor. Das ist nicht dasselbe. Der Name des Standardindex ist _id_ , sein Schlüssel ist _id .
Die _id wird normalerweise clientseitig erstellt, nicht serverseitig. Die Frage ist, woher diese Schlüssel kommen, denn 2ZGvRfuD8iMvRiXJd ist sicherlich keine ObjectId . Dies kann ein Meteorschlüssel sein, oder Sie verwenden einen benutzerdefinierten Primärschlüssel, aber ich weiß nicht, wie diese Schlüssel generiert werden. Vielleicht ist das, was auch immer den Schlüssel generiert, anfällig für Kollisionen?
Weitere Informationen dazu wären hilfreich, aber ich würde vorschlagen, eine neue Frage zu formulieren, damit die Frage nicht zu umfangreich wird oder viel Geschichte bekommt.
Das ist ein Lemma der ersten Antwort:Sie können den obligatorischen Primärschlüsselindex nicht löschen.
Bearbeiten:
Meteor generiert standardmäßig IDs anders als MongoDb
. Das macht Sinn, weil die Konvention für ObjectId macht Kollisionen wahrscheinlich, wenn die Anzahl der Clients groß ist
(d.h. wenn die Clients keine Serverinstanzen sind, sondern Clientbrowser, von denen es wahrscheinlich 2-3 Größenordnungen mehr gibt).
Stattdessen verwendet Meteor offenbar eine Methode, um konsequent Pseudozufallszahlen zu generieren auf Client und Server . Irritierenderweise verwendet die Implementierung ein PRNG und greift auf ein not zurück kryptostarker deterministischer Zufallszahlengenerator (Alea) . Mit anderen Worten, herauszufinden, wie genau Das Generieren Ihrer IDs könnte schwierig sein, da dies von vielen Details Ihrer Umgebung abhängt.
Problemumgehung:Versuchen Sie, ObjectId zu verwenden als Primärschlüssel:
Orders= new Meteor.Collection('Orders', {idGeneration: 'MONGO'});
