Skip to content
Switch branches/tags

Latest commit

* DRIVERS-1519: srvMaxHosts option for limiting SRV seeding

Since this commit adds a "MongoClient Configuration" section to the SRV spec, documentation for the srvServiceName option (introduced in c48d7f4) was also added.

This commit also revises existing sections of the SRV spec test README.

* Specify randomization algorithm and require the same for polling

* Require mongodb+srv scheme to use srvMaxHosts

* Update dates for tentative changelog entries

* Do not expect canonical host names for sharded tests

Seeds do not get replaced for non-canonical host names in sharded topologies. That is only done for replica set topologies.

* Positive srvMaxHosts conflicts with loadBalanced=true and replicaSet

Adds URI Validation section to SRV spec. Notes conflict in Load Balancer spec's URI Validation section. Revises sections in URI Options spec (including directConnection validation).

Adds relevant spec tests to SRV and URI Options specs.

* Use correct SRV record for testing srvMaxHosts with loadBalanced=true

The test4 record is intentionally missing and should not have been used in these tests.

The test3 record resolves to a single host, which is suitable for testing loadBalanced=true in the connection string.

Co-authored-by: Benjamin Rewis <>
Co-authored-by: Kevin Albertson <>

Git stats


Failed to load latest commit information.

MongoDB Specifications


Driver Mantras

When developing specifications -- and the drivers themselves -- we follow the following principles:

Strive to be idiomatic, but favor consistency

Drivers attempt to provide the easiest way to work with MongoDB in a given language ecosystem, while specifications attempt to provide a consistent behavior and experience across all languages. Drivers should strive to be as idiomatic as possible while meeting the specification and staying true to the original intent.

No Knobs

Too many choices stress out users. Whenever possible, we aim to minimize the number of configuration options exposed to users. In particular, if a typical user would have no idea how to choose a correct value, we pick a good default instead of adding a knob.

Topology agnostic

Users test and deploy against different topologies or might scale up from replica sets to sharded clusters. Applications should never need to use the driver differently based on topology type.

Where possible, depend on server to return errors

The features available to users depend on a server's version, topology, storage engine and configuration. So that drivers don't need to code and test all possible variations, and to maximize forward compatibility, always let users attempt operations and let the server error when it can't comply. Exceptions should be rare: for cases where the server might not error and correctness is at stake.

Minimize administrative helpers

Administrative helpers are methods for admin tasks, like user creation. These are rarely used and have maintenance costs as the server changes the administrative API. Don't create administrative helpers; let users rely on "RunCommand" for administrative commands.

Check wire version, not server version

When determining server capabilities within the driver, rely only on the maxWireVersion in the hello response, not on the X.Y.Z server version. An exception is testing server development releases, as the server bumps wire version early and then continues to add features until the GA.

When in doubt, use "MUST" not "SHOULD" in specs

Specs guide our work. While there are occasionally valid technical reasons for drivers to differ in their behavior, avoid encouraging it with a wishy-washy "SHOULD" instead of a more assertive "MUST".

Defy augury

While we have some idea of what the server will do in the future, don't design features with those expectations in mind. Design and implement based on what is expected in the next release.

Case Study: In designing OP_MSG, we held off on designing support for Document Sequences in Replies in drivers until the server would support it. We subsequently decided not to implement that feature in the server.

The best way to see what the server does is to test it

For any unusual case, relying on documentation or anecdote to anticipate the server's behavior in different versions/topologies/etc. is error-prone. The best way to check the server's behavior is to use a driver or the shell and test it directly.

Drivers follow semantic versioning

Drivers should follow X.Y.Z versioning, where breaking API changes require a bump to X. See for more.

Writing Documents

Write documents using reStructuredText, following the MongoDB Documentation Style Guidelines.

Store all source documents in the source/ directory.

Prose test numbering

When numbering prose tests, always use relative numbered bullets (#.). New tests must be appended at the end of the test list, since drivers may refer to existing tests by number.

Outdated tests must not be removed completely, but may be marked as such (e.g. by striking through or replacing the entire test with a note (e.g. Removed).

Building Documents





Converting to JSON



