[DOCS-861] Clarify behavior of findAndModify with upsert Created: 07/Dec/12 Updated: 13/Nov/23 Resolved: 19/Feb/13 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | mongodb-2.2, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Andy Schwerin | Assignee: | Kay Kim (Inactive) |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Participants: | |||||||||||||||||
| Days since reply: | 11 years, 1 day ago | ||||||||||||||||
| Description |
|
If several clients dispatch a findAndModify command on the same target collection, under certain circumstances, multiple documents may be inserted. The simplest case to understand is when all of the findAndModify commands are issued with identical match criteria, say { name: "andy" }. Suppose that initially, no document with { name : "andy" }exists, and there is no unique index on the "name" field. In this case, if several of the findAndModify commands complete the "find" phase of the operation before any engage in the "modify" phase, those instances of the command may all choose to perform an insert of a new document, since no matching document was found. This is the same as the behavior of "update" operations with upsert behavior. In the above example, had there been a unique index on the "name" field, each fAndM command instance would have seen one of the following behaviors:
To implement, for example, a counter with fAndM, use a unique index on the identifying field (like the name), and if an fAndM fails due to unique index constraint violation, simply repeat it. It will not fail due to this race multiple times, unless there is a process deleting counter documents. |
| Comments |
| Comment by auto [ 19/Feb/13 ] |
|
Author: {u'date': u'2013-02-19T21:35:15Z', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}Message: merge: |
| Comment by auto [ 19/Feb/13 ] |
|
Author: {u'date': u'2013-01-15T04:40:19Z', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message:
findAndModify flesh out what is returned
|
| Comment by auto [ 19/Feb/13 ] |
|
Author: {u'date': u'2013-01-15T04:40:19Z', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message:
findAndModify flesh out what is returned
|
| Comment by auto [ 19/Feb/13 ] |
|
Author: {u'date': u'2013-01-15T04:40:19Z', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message:
findAndModify flesh out what is returned
|
| Comment by auto [ 19/Feb/13 ] |
|
Author: {u'date': u'2013-01-15T04:40:19Z', u'name': u'kay', u'email': u'kay.kim@10gen.com'}Message:
findAndModify flesh out what is returned
|