@andreas-jung tiene razón en eso ensure_index() es un contenedor sobre create_index() , creo que la confusión surge con la frase:
Cuando PyMongo crea (o garantiza) un índice, se "recuerda" durante ttlsegundos.
No es que el índice sea temporal o "transitorio", lo que sucede es que durante la cantidad de segundos especificada, una llamada a ensure_index() tratar de crear el mismo índice de nuevo no tendrá ningún efecto y no llama a create_index() debajo, pero después de que caduque ese "caché", una llamada a ensure_index() voluntad llama de nuevo a create_index() debajo.
Entiendo perfectamente tu confusión porque, francamente, los documentos de PyMongo no explican muy bien cómo funciona esto, pero si te diriges a los documentos de Ruby, la explicación es un poco más clara:
- (Cadena) asegurar_index(especificación, opciones ={})
Llama a create_index y establece una marca para que no vuelva a hacerlo durante otros X minutos. Este tiempo se puede especificar como una opción al inicializar un Mongo::DBobject as options[:cache_time] Cualquier cambio en un índice se propagará independientemente del tiempo de caché (por ejemplo, un cambio de dirección del índice)
Los parámetros y opciones de este método son los mismos que los de Collection#create_index.
Ejemplos:
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
No estoy afirmando que los controladores funcionen exactamente igual, es solo que, con fines ilustrativos, su explicación es un poco mejor en mi humilde opinión.
