@andreas-jung heeft gelijk in die ensure_index() is een wrapper over create_index() , Ik denk dat de verwarring ontstaat met de zin:
Wanneer een index is gemaakt (of gegarandeerd) door PyMongo, wordt deze gedurende ttlseconden "onthouden".
Het is niet zo dat de index tijdelijk of "van voorbijgaande aard" is, wat er gebeurt is dat gedurende het opgegeven aantal seconden een aanroep naar ensure_index() proberen om dezelfde index opnieuw te maken zal niet enig effect hebben en zullen niet bel create_index() eronder, maar nadat die "cache" verloopt, een aanroep naar ensure_index() zal bel opnieuw create_index() eronder.
Ik begrijp je verwarring volkomen, want eerlijk gezegd zijn de documenten van PyMongo niet erg goed in het uitleggen hoe dit werkt, maar als je naar de Ruby-documenten gaat, is de uitleg een beetje duidelijker:
- (String) assurance_index(spec, opts ={})
Roept create_index aan en stelt een vlag in om dit niet opnieuw te doen gedurende nog eens X minuten. Deze tijd kan als optie worden opgegeven bij het initialiseren van een Mongo::DBobject als opties[:cache_time] Wijzigingen in een index worden doorgevoerd ongeacht de cachetijd (bijv. een verandering van indexrichting)
De parameters en opties voor deze methode zijn dezelfde als die voorCollection#create_index.
Voorbeelden:
Call sequence:
Time t: @posts.ensure_index([['subject', Mongo::ASCENDING]) -- calls create_index and sets the 5 minute cache
Time t+2min : @posts.ensure_index([['subject', Mongo::ASCENDING]) -- doesn't do anything
Time t+3min : @posts.ensure_index([['something_else', Mongo::ASCENDING]) -- calls create_index and sets 5 minute cache
Time t+10min : @posts.ensure_index([['subject', Mongo::ASCENDING]) -- calls create_index and resets the 5 minute counter
Ik beweer niet dat stuurprogramma's precies hetzelfde werken, maar ter illustratie is hun uitleg een beetje beter IMHO.