Dit zal uw probleem niet oplossen, maar het zou u in de goede richting moeten wijzen en u misschien in staat moeten stellen het probleem te isoleren dat u kunt gebruiken om een nieuwe vraag te maken:
Dat is er niet. Er is maar één index, en deze heeft een naam en een sleutelbeschrijving. Dat is niet hetzelfde. De naam van de standaardindex is _id_ , de sleutel is _id .
De _id wordt normaal gesproken aan de clientzijde gemaakt, niet aan de serverzijde. De vraag is waar die sleutels vandaan komen, want 2ZGvRfuD8iMvRiXJd is zeker geen ObjectId . Dit kan een meteoorsleutel zijn, of je gebruikt een aangepaste primaire sleutel, maar ik weet niet hoe deze sleutels worden gegenereerd. Misschien is alles wat de sleutel genereert vatbaar voor botsingen?
Meer informatie hierover zou nuttig zijn, maar ik stel voor om een nieuwe vraag te formuleren, zodat de vraag niet te groot wordt of veel geschiedenis krijgt.
Dat is een lemma van het eerste antwoord:u kunt de verplichte primaire sleutelindex niet verwijderen.
Bewerken:
Meteor genereert standaard id's op een andere manier dan MongoDb
. Dat is logisch, want de conventie voor ObjectId maakt botsingen waarschijnlijk als het aantal clients groot is
(d.w.z. als de clients geen serverinstanties zijn, maar clientbrowsers, waarvan er waarschijnlijk 2-3 ordes van grootte meer zijn).
In plaats daarvan gebruikt Meteor blijkbaar de methode om consequent pseudo-willekeurige getallen te genereren op client en server . Irritant genoeg gebruikt de implementatie een PRNG en valt terug op een niet crypto-sterke deterministische generator voor willekeurige getallen (Alea) . Met andere woorden, erachter komen hoe precies uw id's worden gegenereerd, kan lastig zijn omdat het afhangt van veel details van uw omgeving.
Tijdelijke oplossing:probeer ObjectId . te gebruiken als primaire sleutel:
Orders= new Meteor.Collection('Orders', {idGeneration: 'MONGO'});