[DOCS-7637] Commands that take a writeConcern Created: 13/Apr/16  Updated: 31/Oct/22

Status: Closed
Project: Documentation
Component/s: Server
Affects Version/s: None
Fix Version/s: 3.4.0

Type: Task Priority: Major - P3
Reporter: Judah Schvimer Assignee: Andrew Aldridge
Resolution: Won't Do Votes: 0
Labels: docs-3.4
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-20224 Commands which write should take a wr... Closed
documents SERVER-22270 applyOps to config rs does not wait f... Closed
Duplicate
is duplicated by DOCS-8300 Commands that write should take a wri... Closed
is duplicated by DOCS-7079 applyOps takes a writeConcern Closed
Related
is related to DOCS-7079 applyOps takes a writeConcern Closed
Participants:
Days since reply: 1 year, 14 weeks, 2 days ago
Story Points: 1

 Description   

Docs changes

  • runCommand() shell helper should describe writeConcern along with an example.
  • We should have an extract file describing writeConcern usage that each command's reference page can include.

Description

All commands, run with runCommand(), that do writes now accept a writeConcern parameter. Special cases are aggregation and mapReduce. Aggregation only accepts a writeConcern when there is a $out stage in the pipeline. MapReduce only accepts a writeConcern when the "out" option is not set to inline (as in when it outputs to a collection).

A full list of commands that accept a writeConcern can be found here: https://docs.google.com/document/d/1AuKO0IgdwUGw9h-PlyIkZqVtSk_vxF74HxntDTXoGdo/edit#heading=h.ulqd0rufx0m2
Additionally, if there is any question about if a command accepts a writeConcern parameter, every command in the server overrides the function "supportsWriteConcern", specifying if it supports writeConcern.

All commands that support writeConcern accept it as a parameter to runCommand(). No changes were made to the shell or its helpers, so depending on how shell helpers handle their arguments, shell helpers may or may not accept a writeConcern parameter. For example, createCollection accepts a writeConcern argument in its options object, but dropCollection does not accept any arguments.

If a writeConcern is supplied to a command that does not accept writeConcern, the command will not execute and will fail.

If an invalid writeConcern is passed to a command that supports writeConcern, behavior depends on the cluster topology. On a standalone server (which accepts writeConcern for journalling purposes), invalid writeConcern arguments will yield a command failure before the command is run. This means that the command will not actually be executed. For failures on replicasets and sharded clusters, the writeConcern validity is only checked after the command is run, and thus the command will still execute on the primary. The primary will just not wait for replication before returning to the user. In this case the user will receive a writeConcernError field in their response.

If the writeConcern fails due to a replication timeout, the failure will occur after the command has executed on the primary, but the data may not be visible on the secondaries yet. The user will receive a writeConcernError field in their response.

Write concern error responses have not changed for commands that already support writeConcern. In most cases, if waiting for writeConcern fails (due to timeout or an invalid writeConcern parameter) the user receives a writeConcernError field in their response in addition to ok: 1. For user management commands where in the past writeConcern errors yielded ok: 0, the command will return a writeConcernError in addition to ok: 0 (same as its behavior in 3.2). Finally, for commands on mongos that do writes on the config servers, the response will contain ok: 0 and will not have a writeConcernError. Commands that do writes to both the shards and config servers will yield ok: 1 if the writeConcern failure occurs on the shards and ok: 0 if it occurs on the config servers.



 Comments   
Comment by Education Bot [ 31/Oct/22 ]

Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you!

Comment by Andrew Aldridge [ 16/Sep/16 ]

(Copied emily.hall's comment on now-closed DOCS-8300)
Commands from the scope document:

aggregate with $out
applyOps
clone
cloneCollection
cloneCollectionAsCapped
collMod
convertToCapped
copydb
create
createIndexes
drop
dropDatabase
dropIndexes
emptyCapped
mapReduce with $out
renameCollection

Comment by Bernie Hackett [ 13/Sep/16 ]

jeff.yemin, jinx, you owe me a coke.

Comment by Jeffrey Yemin [ 13/Sep/16 ]

Yes.

Comment by Bernie Hackett [ 13/Sep/16 ]

Yes

Generated at Thu Feb 08 07:54:41 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.