Use Case

As a... user of the driver
I want... clear differentiation between legacy write concern options and non-legacy write concern options
So that... it's clear how I should specify the write concern

User Impact

• __ Anyone interacting with the WriteConcern class or write concern settings

Dependencies

• N/A

Unknowns

• N/A

Acceptance Criteria

Implementation Requirements

• Mark fsync, j, and wtimeout as deprecated in the WriteConcernSettings class
• Add w, journal, and wtimeoutMS as public readonly properties to the WriteConcern class

• Mark fsync, j, and wtimeout as deprecated on the WriteConcern class
• Update the constructor to use the wtimeoutMS and journal instead of wtimeout and j as variable names
• Add a static WriteConcern.apply method that applies a write concern to a command document and transforms the public options into the format expected by the server (j, w, and wtimeout) - ensure that it can still handle the deprecated options
• Update internal code to use this method to apply the write concern to the command; for compatibility, ensure that the legacy properties are still set if the new properties are not specified
  • Remember to update the gridfs implementation, too (e.g., getWriteOptions)

Testing Requirements

• Unit test the new static method
• Do NOT update existing integration tests to use the new options in order to ensure we don't break compat with the legacy options; instead, add new tests to make sure the new WriteConcern options are applied and sent on commands to the server as expected

Documentation Requirements

• Update the API docs for the modified methods and properties to make sure they don't incorrectly reference the legacy options

Follow Up Requirements

• N/A