@andreas-jung ma rację w tym ensure_index() jest opakowaniem dla create_index() , myślę, że zamieszanie pojawia się przy zdaniu:
Kiedy indeks jest tworzony (lub zapewniany) przez PyMongo, jest on „zapamiętywany” przez ttlsekundy.
Nie chodzi o to, że indeks jest tymczasowy lub „przejściowy”, dzieje się tak, że w ciągu określonej liczby sekund wywołanie ensure_index() próba ponownego utworzenia tego samego indeksu nie mają jakikolwiek wpływ i nie wywołaj create_index() poniżej, ale po wygaśnięciu „pamięci podręcznej” wywołanie ensure_index() będzie ponownie wywołaj create_index() pod spodem.
Doskonale rozumiem twoje zmieszanie, ponieważ, szczerze mówiąc, dokumenty PyMongo nie wykonują zbyt dobrej pracy w wyjaśnianiu, jak to działa, ale jeśli przejdziesz do dokumentacji Rubiego, wyjaśnienie jest trochę jaśniejsze:
- (String) secure_index(spec, opts ={})
Wywołuje create_index i ustawia flagę, aby nie robić tego ponownie przez kolejne X minut. Ten czas można określić jako opcję podczas inicjowania Mongo::DBobject jako options[:cache_time] Wszelkie zmiany w indeksie będą propagowane niezależnie od czasu pamięci podręcznej (np. zmiana kierunku indeksu)
Parametry i opcje tej metody są takie same jak te dla kolekcji#create_index.
Przykłady:
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
Nie twierdzę, że sterowniki działają dokładnie tak samo, po prostu dla celów ilustracyjnych ich wyjaśnienie jest trochę lepsze IMHO.
