@andreas-jung har ret i det ensure_index() er en indpakning over create_index() , jeg tror, at forvirringen opstår med sætningen:
Når et indeks er oprettet (eller sikret) af PyMongo, "huskes det" i ttlsesekunder.
Det er ikke, at indekset er midlertidigt eller "forbigående", hvad der sker er, at der i løbet af det angivne antal sekunder, et kald til ensure_index() at prøve at oprette det samme indeks igen vil ikke har nogen virkning og vil ikke kald create_index() nedenunder, men efter at "cachen" udløber, et kald til ensure_index() vil kald igen create_index() nedenunder.
Jeg forstår udmærket din forvirring, for ærligt talt gør PyMongos dokumenter ikke et særlig godt stykke arbejde med at forklare, hvordan dette fungerer, men hvis du går over til Ruby-dokumenterne, er forklaringen lidt klarere:
- (String) sure_index(spec, opts ={})
Kalder create_index og sætter et flag for ikke at gøre det igen i yderligere X minutter. denne gang kan angives som en valgmulighed ved initialisering af et Mongo::DB-objekt som optioner[:cache_time] Enhver ændring af et indeks vil blive propageret igennem uanset cache-tid (f.eks. ændring af indeksretning)
Parametrene og mulighederne for denne metode er de samme som dem for Collection#create_index.
Eksempler:
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
Jeg påstår ikke, at drivere fungerer nøjagtigt det samme, det er bare, at deres forklaring til illustrationsformål er lidt bedre IMHO.