More cross linking cleanup fixing intersphinx links

Author: Ed Costello

source/use-cases/metadata-and-asset-management.txt

@@ -150,7 +150,8 @@ Procedure
 `````````
 
 The most common operations inside of a CMS center on creating and
-editing content. Consider the following :py:meth:`<pymongo:pymongo.collection.Collection.insert>`
+editing content. Consider the following
+:py:meth:`insert() <pymongo:pymongo.collection.Collection.insert>`
 operation:
 
 .. code-block:: python
@@ -265,7 +266,7 @@ upon the basic update procedure:
 
 Because uploading the photo spans multiple documents and is a
 non-atomic operation, you must "lock" the file during upload by
-writing :py:class:`datetime.utcnow() <python:datetime.utcnow>` in the
+writing :py:meth:`datetime.utcnow() <python:datetime.datetime.utcnow>` in the
 record. This helps when there are multiple concurrent editors and lets
 the application detect stalled file uploads. This operation assumes
 that, for photo upload, the last update will succeed:

source/use-cases/product-catalog.txt

@@ -525,24 +525,27 @@ per-connection or per-operation basis. In :api:`PyMongo
 <python/current>`, set the :py:attr:`read_preference
 <pymongo.collection.Collection.read_preference>` argument.
 
-The :py:class:`SECONDARY <pymongo:pymongo.ReadPreference>` property in
-the following example, permits reads from a :term:`secondary` (as well
-as a primary) for the entire connection .
+The
+:py:attr:`SECONDARY <pymongo:pymongo.connection.Connection.read_preference>`
+property in the following example, permits reads from a
+:term:`secondary` (as well as a primary) for the entire connection .
 
 .. code-block:: python
 
    conn = pymongo.Connection(read_preference=pymongo.SECONDARY)
 
-Conversely, the :py:class:`SECONDARY_ONLY
-<pymongo:pymongo.ReadPreference>` read preference means that the
+Conversely, the
+:py:attr:`SECONDARY_ONLY <pymongo:pymongo.connection.Connection.read_preference>`
+read preference means that the
 client will only send read operation only to the secondary member
 
 .. code-block:: python
 
    conn = pymongo.Connection(read_preference=pymongo.SECONDARY_ONLY)
 
-You can also specify :py:attr:`read_preference
-<pymongo.collection.Collection.read_preference>` for specific queries,
+You can also specify
+:py:attr:`read_preference <pymongo.collection.Collection.read_preference>`
+for specific queries,
 as follows:
 
 .. code-block:: python

source/use-cases/storing-log-data.txt

@@ -409,7 +409,8 @@ following command:
    >>> db.events.ensure_index([('time', 1), ('host', 1)])
 
 To analyze the performance for the above query using this index, issue
-the :py:meth:`q_events.explain() <pymongo:pymongo.collection.Collection.explain>`
+the
+:py:meth:`q_events.explain() <pymongo:pymongo.cursor.Cursor.explain>`
 method in a Python console. This will return something that resembles:
 
 .. code-block:: pycon
@@ -437,7 +438,8 @@ index using the following operation:
 
    >>> db.events.ensure_index([('host', 1), ('time', 1)])
 
-Use the :py:meth:`q_events.explain() <pymongo:pymongo.collection.Collection.explain>`
+Use the
+:py:meth:`q_events.explain() <pymongo:pymongo.cursor.Cursor.explain>`
 operation to test the performance:
 
 .. code-block:: pycon
@@ -489,9 +491,9 @@ Aggregation
 
 The :term:`aggregation framework` provides the capacity for queries
 that select, process, and aggregate results from large numbers of
-documents. The :method:`aggregate()` (and :dbcommand:`aggregate`
+documents. The :method:`aggregate() <db.collection.aggregate()>` (and :dbcommand:`aggregate`
 :term:`command <database command>`) offers greater flexibility,
-capacity with less complexity than the existing :dbcommand:`mapreduce`
+capacity with less complexity than the existing :dbcommand:`mapReduce <mapReduce>`
 and :dbcommand:`group` aggregation.
 
 Consider the following aggregation :term:`pipeline`: [#sql-aggregation-equivalents]_