Skip to content

DOCSP-15419 fix tab titles with ellipses #5207

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 4 additions & 4 deletions source/core/replica-set-sync.txt
Original file line number Diff line number Diff line change
Expand Up @@ -122,7 +122,7 @@ the list of all replica set members:

.. tabs::

.. tab:: Sync Source Selection (First Pass)
.. tab:: First Pass
:tabid: firstpass

The member applies the following criteria to each replica
Expand Down Expand Up @@ -164,7 +164,7 @@ the list of all replica set members:
the member performs a second pass with relaxed criteria.
See :guilabel:`Sync Source Selection (Second Pass)`.

.. tab:: Sync Source Selection (Second Pass)
.. tab:: Second Pass
:tabid: second pass

The member applies the following criteria to each replica
Expand Down Expand Up @@ -293,7 +293,7 @@ through the list of all replica set members:

.. tabs::

.. tab:: Sync Source Selection (First Pass)
.. tab:: First Pass
:tabid: firstpass

The member applies the following criteria to each replica
Expand Down Expand Up @@ -334,7 +334,7 @@ through the list of all replica set members:
the member performs a second pass with relaxed criteria.
See the :guilabel:`Sync Source Selection (Second Pass)`.

.. tab:: Sync Source Selection (Second Pass)
.. tab:: Second Pass
:tabid: second pass

The member applies the following criteria to each replica
Expand Down
61 changes: 47 additions & 14 deletions source/reference/method/db.collection.update.txt
Original file line number Diff line number Diff line change
Expand Up @@ -406,11 +406,17 @@ Write Concerns and Transactions
Examples
--------

The following tabs showcase a variety of common
:method:`~db.collection.update()` operations.

.. tabs::

.. tab:: Use Update Operator Expressions ($inc, $set)
.. tab:: Set
:tabid: op-expr

Use Update Operator Expressions (``$inc`` and ``$set``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. include:: /includes/fact-update-example-docs-intro.rst

.. include:: /includes/fact-update-example-docs.rst
Expand Down Expand Up @@ -509,9 +515,12 @@ Examples
:doc:`/reference/operator/update`,
:ref:`dot notation <document-dot-notation>`

.. tab:: Push Elements to Existing Array
.. tab:: Arrays
:tabid: push-elements-existing-array

Push Elements to Existing Array (``$push``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. include:: /includes/fact-update-example-docs-intro.rst

.. include:: /includes/fact-update-example-docs.rst
Expand Down Expand Up @@ -558,9 +567,12 @@ Examples

:update:`$push`

.. tab:: Remove Fields ($unset)
.. tab:: Unset
:tabid: remove-fields

Remove Fields (``$unset``)
~~~~~~~~~~~~~~~~~~~~~~~~~~

.. include:: /includes/fact-update-example-docs-intro.rst

.. include:: /includes/fact-update-example-docs.rst
Expand Down Expand Up @@ -607,9 +619,12 @@ Examples

:update:`$unset`, :update:`$rename`, :doc:`/reference/operator/update`

.. tab:: Replace Entire Document
.. tab:: Replace
:tabid: replace-doc

Replace Entire Document (``$update``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. include:: /includes/fact-update-example-docs-intro.rst

.. include:: /includes/fact-update-example-docs.rst
Expand Down Expand Up @@ -681,9 +696,12 @@ Examples
150,
"baking,cooking")

.. tab:: Update Multiple Documents
.. tab:: Multiple
:tabid: update-multiple

Update Multiple Documents (``$update`` With ``multi``)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. include:: /includes/fact-update-example-docs-intro.rst

.. include:: /includes/fact-update-example-docs.rst
Expand Down Expand Up @@ -786,11 +804,17 @@ include the full shard key in the ``filter``. For additional
:method:`db.collection.update()` behavior on a sharded collection, see
:ref:`update-sharded-collection`.

The following tabs showcase a variety of uses of the ``upsert`` modifier
with :method:`~db.collection.update()`.

.. tabs::

.. tab:: Upsert with Replacement Document
.. tab:: Replace
:tabid: upsert-example

Upsert with Replacement Document
````````````````````````````````

If no document matches the query criteria and the ``<update>``
parameter is a replacement document (i.e., contains only field
and value pairs), the update inserts a new document with the
Expand Down Expand Up @@ -857,9 +881,12 @@ include the full shard key in the ``filter``. For additional
"tags" : [ "database" ]
}

.. tab:: Upsert with Operator Expressions
.. tab:: Set
:tabid: upsert-op-expr

Upsert with Operator Expressions (``$set``)
```````````````````````````````````````````

If no document matches the query criteria and the ``<update>``
parameter is a document with :ref:`update operator expressions
<update-operators>`, then the operation creates a base document
Expand Down Expand Up @@ -902,9 +929,12 @@ include the full shard key in the ``filter``. For additional

:update:`$setOnInsert`

.. tab:: Aggregation Pipeline using Upsert
.. tab:: Aggregation
:tabid: agg-pipeline-upsert

Upsert using an Aggregation Pipeline
````````````````````````````````````

If the ``<update>`` parameter is an :ref:`aggregation pipeline
<update-behavior-agg-pipeline>`, the update creates a base
document from the equality clauses in the ``<query>``
Expand Down Expand Up @@ -959,11 +989,11 @@ include the full shard key in the ``filter``. For additional
For additional examples of updates using
aggregation pipelines, see :ref:`update-behavior-agg-pipeline`.

.. tab:: Combine Upsert and Multi Options
.. tab:: Multiple
:tabid: combine-upsert-multi

Combine Upsert and Multi Options (Match)
````````````````````````````````````````
Using ``upsert`` with ``multi`` (Match)
```````````````````````````````````````

From the :binary:`~bin.mongo` shell, insert the following
documents into a ``books`` collection:
Expand Down Expand Up @@ -1024,8 +1054,8 @@ include the full shard key in the ``filter``. For additional
"tags" : [ "literature", "translated" ]
}

Combine Upsert and Multi Options (No Match)
```````````````````````````````````````````
Using ``upsert`` with ``multi`` (No Match)
``````````````````````````````````````````

If the collection had *no* matching document, the operation
would result in the insertion of a single document using the
Expand Down Expand Up @@ -1055,9 +1085,12 @@ include the full shard key in the ``filter``. For additional
"tags" : [ "literature", "hardcover" ]
}

.. tab:: Upsert with Dotted _id Query
.. tab:: Dotted ``_id``
:tabid: upsert-dotted-id

Upsert with Dotted ``_id`` Query
````````````````````````````````

.. include:: /includes/fact-upsert-id.rst

The ``WriteResult`` of the operation returns the following
Expand Down
159 changes: 84 additions & 75 deletions source/reference/method/sh.updateZoneKeyRange.txt
Original file line number Diff line number Diff line change
Expand Up @@ -198,8 +198,8 @@ the appropriate permissions for issuing :method:`sh.updateZoneKeyRange()`. See
the documentation page for :ref:`Role-Based Access Control <authorization>`
for more information.

Example
-------
Examples
--------

Given a sharded collection ``exampledb.collection`` with a shard key of ``{ a
: 1 }``, the following operation creates a range with a lower bound of ``1``
Expand Down Expand Up @@ -276,85 +276,94 @@ initial chunk creation and distribution. See
:ref:`updateZoneKeyRange-method-init-chunk-distribution-compound-hashed`
for more information.

Each of the following tabs contains an example specific to the
described shard key type:
The sections below contain examples for three different shard key types.

.. tabs::
Consider the following examples, which explore pre-defining zones or
zone ranges for three different shard key types:

- :ref:`updatezonekeyrange-single-or-compound-example`
- :ref:`updatezonekeyrange-compound-prefix-hashed-example`
- :ref:`updatezonekeyrange-compound-non-prefix-hashed-example`

.. _updatezonekeyrange-single-or-compound-example:

Single or Compound Shard Keys
`````````````````````````````

.. tab:: Single or Compound Shard Keys
:tabid: single-or-compound
.. note::

.. note::

The content in this tab only applies to single-field or
compound shard keys *without* a hashed field.
This example only applies to single-field or compound shard keys
*without* a hashed field.

For example, ``{ "zip" : 1 }`` or
``{ "zip" : 1, "account" : 1}``

.. include:: /includes/steps/zones-initial-chunk-distribution-single-compound.rst

.. tab:: Compound Hashed Shard Key with Hashed Prefix
:tabid: compound-hashed

.. note::

The content in this tab only applies to compound hashed shard
keys where the hashed field is the prefix of the shard key (i.e.
the first field in the shard key is hashed).

For example, ``{ "_id" : "hashed", "facility" : 1 }``

Starting in version 4.4, MongoDB supports sharding collections on
:ref:`compound hashed indexes <index-type-compound-hashed>`. When
sharding on a compound hashed shard key, MongoDB can perform
optimized initial chunk creation and distribution on the empty or
non-existing collection *only if* the defined zone ranges meet
:ref:`additional requirements
<updateZoneKeyRange-method-init-chunk-distribution>`.

Consider an empty collection ``examples.metrics`` which will store
analytics from one of two manufacturing facilities. The
planned shard key is ``{ "_id" : "hashed", "facility" : 1}``,
where the hashed field is the shard key *prefix*.
For example, ``{ "zip" : 1 }`` or
``{ "zip" : 1, "account" : 1}``

.. include:: /includes/steps/zones-initial-chunk-distribution-single-compound.rst

.. _updatezonekeyrange-compound-prefix-hashed-example:

Compound Hashed Shard Key with Hashed Prefix
````````````````````````````````````````````

.. note::

This example only applies to compound hashed shard keys where the
hashed field is the prefix of the shard key (i.e. the first field in
the shard key is hashed).

For example, ``{ "_id" : "hashed", "facility" : 1 }``

Starting in version 4.4, MongoDB supports sharding collections on
:ref:`compound hashed indexes <index-type-compound-hashed>`. When
sharding on a compound hashed shard key, MongoDB can perform
optimized initial chunk creation and distribution on the empty or
non-existing collection *only if* the defined zone ranges meet
:ref:`additional requirements
<updateZoneKeyRange-method-init-chunk-distribution>`.

Consider an empty collection ``examples.metrics`` which will store
analytics from one of two manufacturing facilities. The
planned shard key is ``{ "_id" : "hashed", "facility" : 1}``,
where the hashed field is the shard key *prefix*.

.. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-prefix.rst

.. tab:: Compound Hashed Shard Key with Non-Prefix Hashed Field
:tabid: compound-hashed-no-prefix

.. note::

The content in this tab only applies to compound hashed shard
keys where the hashed field is *not* the prefix of the shard key
(i.e. the first field in the shard key is not hashed).

For example, ``{ "facility" : 1, "_id" : "hashed" }``

Starting in version 4.4, MongoDB supports sharding collections on
:ref:`compound hashed indexes <index-type-compound-hashed>`. When
sharding on a compound hashed shard key, MongoDB can perform
optimized initial chunk creation and distribution on the empty or
non-existing collection *only if* the defined zone ranges meet
:ref:`additional requirements
<updateZoneKeyRange-method-init-chunk-distribution>`.

Consider an empty collection ``examples.metrics`` which will store
analytics from one of two manufacturing facilities. The planned
shard key is ``{ "facility" : 1, "_id" : "hashed" }``, where
the hashed field is *not* the shard key prefix.

- The ``facility`` field stores the name of the facility:
``"FacilityAlpha"`` or ``"FacilityBaker"``. The
collection requires zone ranges on ``facility`` to help isolate
data for each facility to specific shards.

- The ``_id`` field compensates for the low-cardinality of the
``facility`` field. Hashing compensates for the
monotonically-increasing nature of the ``_id`` field.

.. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-non-prefix.rst
.. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-prefix.rst

.. _updatezonekeyrange-compound-non-prefix-hashed-example:

Compound Hashed Shard Key with Non-Prefix Hashed Field
``````````````````````````````````````````````````````

.. note::

This example only applies to compound hashed shard keys where the
hashed field is *not* the prefix of the shard key (i.e. the first
field in the shard key is not hashed).

For example, ``{ "facility" : 1, "_id" : "hashed" }``

Starting in version 4.4, MongoDB supports sharding collections on
:ref:`compound hashed indexes <index-type-compound-hashed>`. When
sharding on a compound hashed shard key, MongoDB can perform
optimized initial chunk creation and distribution on the empty or
non-existing collection *only if* the defined zone ranges meet
:ref:`additional requirements
<updateZoneKeyRange-method-init-chunk-distribution>`.

Consider an empty collection ``examples.metrics`` which will store
analytics from one of two manufacturing facilities. The planned
shard key is ``{ "facility" : 1, "_id" : "hashed" }``, where
the hashed field is *not* the shard key prefix.

- The ``facility`` field stores the name of the facility:
``"FacilityAlpha"`` or ``"FacilityBaker"``. The
collection requires zone ranges on ``facility`` to help isolate
data for each facility to specific shards.

- The ``_id`` field compensates for the low-cardinality of the
``facility`` field. Hashing compensates for the
monotonically-increasing nature of the ``_id`` field.

.. include:: /includes/steps/zones-initial-chunk-distribution-compound-hashed-non-prefix.rst

.. seealso::

Expand Down
Loading