@andreas-jung ha ragione in quel ensure_index() è un wrapper su create_index() , penso che la confusione sorga con la frase:
Quando un indice viene creato (o garantito) da PyMongo, viene "ricordato" per ttlsecondi.
Non è che l'indice sia temporaneo o "transitorio", quello che succede è che durante la quantità di secondi specificata, una chiamata a ensure_index() provare a creare di nuovo lo stesso indice non avere alcun effetto e non chiama create_index() sotto, ma dopo la scadenza di quella "cache", una chiamata a ensure_index() farà chiama di nuovo create_index() sotto.
Capisco perfettamente la tua confusione perché francamente i documenti di PyMongo non fanno un ottimo lavoro nello spiegare come funziona, ma se vai ai documenti di Ruby, la spiegazione è un po' più chiara:
- (Stringa) sure_index(spec, opts ={})
Chiama create_index e imposta un flag per non farlo di nuovo per altri X minuti. Questa volta può essere specificata come opzione durante l'inizializzazione di un Mongo::DBobject come opzioni[:cache_time] Eventuali modifiche a un indice verranno propagate indipendentemente dal tempo della cache (ad es. cambio di direzione dell'indice)
I parametri e le opzioni per questo metodo sono gli stessi di quelli perCollection#create_index.
Esempi:
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
Non sto affermando che i driver funzionino esattamente allo stesso modo, è solo che a scopo illustrativo la loro spiegazione è leggermente migliore IMHO.
