@@ -466,41 +466,36 @@ driver <>`.
466466
467467 db.getCollection("_foo").find()
468468
469- .. _faq-developers-snapshot-queries :
469+ .. _faq-developers-isolate-cursors :
470470
471- How do I perform a snapshot query in MongoDB ?
472- ---------------------------------------------
471+ How do I isolate cursors from intervening write operations ?
472+ -----------------------------------------------------------
473473
474- MongoDB does not support full point-in-time snapshot where the cursor
475- returned from a query points to the records at the time of the
476- query execution, regardless of additional write operations that may
477- have occurred during the lifetime of the cursor. However, MongoDB does
478- provides a :method:`snapshot() <cursor.snapshot()>` method to prevent
479- the case where a cursor could return a document more than once because
480- an intervening write operation results in a move of the document due to
481- the growth in document size.
474+ During the lifetime of the cursor, an intervening write operation can
475+ result in a move of the document due to the growth in document size.
476+ This may cause the cursor to return the document more than once. To
477+ prevent this from happening, you can use the :method:`snapshot()
478+ <cursor.snapshot()>` method.
482479
483- When applied to the cursor returned from :method:`find()`,
484- :method:`snapshot() <cursor.snapshot()>` assures that the cursor
485- returns a document no more than once.
480+ The :method:`snapshot() <cursor.snapshot()>` method traverses the index
481+ on the ``_id`` field. As such, :method:`snapshot() <cursor.snapshot()>`
482+ **cannot** be used with :method:`sort() <cursor.sort()>` or
483+ :method:`hint() <cursor.hint()>`.
486484
487- .. note::
485+ The :method:`snapshot() <cursor.snapshot()>` does not guarantee
486+ isolation from insertion or deletions.
487+
488+ .. warning::
489+
490+ You can only use :method:`snapshot() <cursor.snapshot()>` with
491+ **unsharded** collections.
492+
493+ Alternatively, if there are field or fields that are never modified,
494+ you can use a *unique* index on this field or these fields to achieve
495+ the same effect as the :method:`snapshot() <cursor.snapshot()>`. Query
496+ with :method:`hint() <cursor.hint()>` to explicitly force the use of
497+ that index.
488498
489- - Even with :method:`snapshot() <cursor.snapshot()>`, objects
490- inserted or deleted during the lifetime of the cursor may or may
491- not be returned.
492-
493- - The :method:`snapshot() <cursor.snapshot()>` method traverses the
494- index on the ``_id``. As such, :method:`snapshot()
495- <cursor.snapshot()>` **cannot** be used with :method:`sort()
496- <cursor.sort()>` or :method:`hint() <cursor.hint()>`. No other
497- index can be used for the query.
498-
499- - Alternatively, instead of :method:`snapshot()
500- <cursor.snapshot()>`, you can use a *unique* index on field(s)
501- that will not be modified and use :method:`hint() <cursor.hint()>`
502- to explicitly force that index during the query in order to
503- achieve the same :method:`snapshot() <cursor.snapshot()>` mode.
504- Additionally, to use a non-unique index on field(s) that will not
505- be modified, you can create a unique index by including the
506- ``_id`` field to the index fields.
499+ If you want to use a non-unique index on field(s) that will not be
500+ modified, you can create a unique index by including the ``_id`` field
501+ to the index fields.
0 commit comments