This commit introduces the following changes:
- Each read preference is now a class.
- Read preferences other than Primary accept a tag_sets parameter.
- The tag_sets attribute of MongoClient, Database, and Collection has
been removed. Use the tag_sets parameter of the new classes instead.
- The read_preferences.ReadPreference constant still exists and should
continue to work as expected for most users.
- Renamed to acceptableLatencyMS since it is also used
in choosing a new mongos during mongos HA failover.
- Moved to a global immutable setting. The expectation is
that the value would be determined by a network/system
admin. Changing it per operation doesn't make a lot of
sense.
Note - it's possible the name of this option may change again
before 3.0 is released.
MongoDB master/slave clusters are deprecated. Use replica
sets instead. If you must use this client class the 2.x
branch of PyMongo will continue to be maintained for some
time.
This was always a misguided feature. Using a socket timeout
to "timeout" MongoDB queries is awful for a few reasons:
- It leaves the query running on the server, wasting resources.
- It causes a socket to be closed and discarded unnecessarily.
- Applications that use this tend to immediately retry the query,
often causing another timeout and more wasted resources.
There are three remaining ways to use timeouts with PyMongo:
- connectTimeoutMS - Global setting for timing out a socket's
initial connection to the server.
- socketTimeoutMS - Global setting for timing out any socket
operation. *Do not* use this to enforce time limits on server
side operations.
- max_time_ms (or maxTimeoutMS as a command kwarg) - MongoDB 2.6
server side timebomb for queries and commands. This is a server
side option, passed along with a query or command, that causes
MongoDB to abort the operation if it takes longer than the specified
limit.
If you need to continue to use any of these Python versions with MongoDB
the 2.x branch of PyMongo will continue to be minimally maintained for
some time.
This reduces memory fragmentation when encoding large
batches of documents for insert. Testing shows improvements
in memory usage in pure python and reduced GC overhead in
Jython with no reduction in performance.
There are two Kerberos bindings on PyPI: kerberos and pykerberos.
PyMongo has been compatible with the kerberos package since PyMongo 2.5.0. But kerberos is not currently compatible with Python 3.
This change introduces compatibility with the new pykerberos package. Since pykerberos is compatible with Python 3, PyMongo can now use Kerberos in Python 3.
PyMongo has been tested against python 3.4 rc1 - rc3. We'll
probably wait until 3.4 final to update trove classifiers.
*NOTE* - Testing with 3.4 requires nose 1.3.1 due to
https://github.com/nose-devs/nose/issues/759
In a sharded cluster with mixed version shards (i.e.
one shard primary is 2.6, another is 2.4 or older) the
result of one call to update could include nModified
when the next does not. Since there is no way to provide
a valid count in this case we omit the field. Make sure
you upgrade your entire cluster to MongoDB 2.6 or newer
before relying on this field.
test_gridfs_secondary_lazy asserts that get_last_version on a secondary raises
NoFile. This fails if setUp()'s dropCollection command hasn't yet replicated:
there's still a file on the secondary.
