Skip to content

Commit adf2420

Browse files
committed
Fixed typos
1 parent 7656e60 commit adf2420

22 files changed

+36
-36
lines changed

draft/applications/geospatial-indexes.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -35,7 +35,7 @@ command, this is the same as running database commands.
3535

3636
The :dbcommand:`geoNear` command is more specialized as it returns
3737
detailed geospatial information for each result such as distance and
38-
overall query performance. This provides addtional benefits when only
38+
overall query performance. This provides additional benefits when only
3939
working with geospatial data.
4040

4141
.. TODO does it make sense to have this here??
@@ -371,7 +371,7 @@ spherical geometry is the ``{ spherical: true }`` option.
371371
sphere (e.g. the Earth) in the same units as the distance
372372
measurement.
373373

374-
- *radians to distnace*: multiply the radian measure by the radius
374+
- *radians to distance*: multiply the radian measure by the radius
375375
of the sphere (e.g. the Earth) in the units system that you want to
376376
convert the distance to.
377377

@@ -566,7 +566,7 @@ model:
566566
}
567567

568568
The values of the array may either be arrays holding coordinates, as
569-
in ``[ 55.5, 42.3 ]`` or embeded documents as in ``{ "lat": 55.3,
569+
in ``[ 55.5, 42.3 ]`` or embedded documents as in ``{ "lat": 55.3,
570570
"long": 40.2 }``.
571571

572572
You could then create a geospatial index on the ``locs`` field, as in

draft/core/read-operations.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -288,7 +288,7 @@ Replica Sets
288288

289289
:term:`Replica sets <replica set>` use :term:`read preferences <read
290290
preference>` to determine where and how to route read operations. By
291-
default, MongoDB always reads data from a repilca set's :term:`primary`.
291+
default, MongoDB always reads data from a replica set's :term:`primary`.
292292
You can modify that behavior by changing the :ref:`read preference mode
293293
<replica-set-read-preference-modes>`.
294294

draft/faq-sharding-addition.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,7 @@ In the following cases, we recommend pre-splitting before a large insert:
2525
chunks. By pre-splitting and using an increasing shard key, you can
2626
prevent writes from monopolizing a single :term:`shard`.
2727

28-
- Monotomically increasing shard key.
28+
- Monotonically increasing shard key.
2929

3030
If you attempt to insert data with monotonically increasing shard
3131
keys, the writes will always occur on the last chunk in the

draft/tutorial/expire-least-recently-used-data.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ Least recently used, or LRU, data retention patterns are used in simple
1010
data caches or support for stateless systems. By extending TTL
1111
collections with application support provides additional features.
1212

13-
This pattern presents some cases and proides a pattern for maintaining
13+
This pattern presents some cases and provides a pattern for maintaining
1414
documents in MongoDB where LRU documents are retained while others are
1515
removed using the TTL collection feature.
1616

draft/use-cases/ad-campaign-management.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ Online Advertising: Campaign Management
99
Overview
1010
--------
1111

12-
This document outlines the basic patterns and principless for using
12+
This document outlines the basic patterns and principles for using
1313
MongoDB as a persistent storage engine for an online advertising network. In
1414
particular, this document focuses on creating and maintaining an advertising
1515
campaign with a pre-set daily budget and cost per click (CPC) and cost per

draft/use-cases/gaming-user-state.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ include:
3333
location to another, the character needs to track this.
3434

3535
In addition, you need to store all this data for large numbers of
36-
playerss who might be playing the game simultaneously, and this data
36+
players who might be playing the game simultaneously, and this data
3737
needs to be both readable and writeable with minimal latency in order
3838
to ensure responsiveness during gameplay.
3939

@@ -143,7 +143,7 @@ There are a few things to note about this document:
143143
.. should note that using unbounded lists on items can be an issue, past 1000 entries should prob normalize.
144144
Also if it ends up being much larger than core data itself, may want to split into own document, to better use RAM.
145145

146-
.. Dont understand why the whole location info is stored here: lots of duplication and consistency issues.
146+
.. Don't understand why the whole location info is stored here: lots of duplication and consistency issues.
147147
Should normalize here and just store location name / coordinates
148148

149149
Items
@@ -361,7 +361,7 @@ To actually display weapons, then, you would use the following code:
361361

362362
.. code-block:: pycon
363363

364-
>>> armor = get_weapons_for_dislay(character, item_index)
364+
>>> armor = get_weapons_for_display(character, item_index)
365365

366366
Displaying Character Attributes, Inventory, and Room Information
367367
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

draft/use-cases/serving-ads.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ Serving and Tracking Online Advertisements
77
Overview
88
--------
99

10-
This document outlines basic patterns and principless for using
10+
This document outlines basic patterns and principles for using
1111
MongoDB as a persistent storage engine for an online advertising
1212
network. In particular, this document focuses on the task of deciding
1313
*which* ad to serve when a user visits a particular site.
@@ -243,7 +243,7 @@ Querying
243243
````````
244244

245245
Use the following query to choose an ad to serve. This operation must
246-
iterate through ads in order of "desireability" and then select the
246+
iterate through ads in order of "desirability" and then select the
247247
"best" ad that also satisfies the advertiser's targeting rules. In
248248
this example the frequency cap is the targeting rule.
249249

@@ -293,7 +293,7 @@ determine if it meets the advertiser's rules.
293293

294294
The ``ad_is_acceptable()`` function then iterates over all
295295
``impressions`` in the user's' profile, from most recent to oldest,
296-
within a certain ``thresold`` time period, which is 1 day in the
296+
within a certain ``threshold`` time period, which is 1 day in the
297297
sample above. If the same ``ad_unit_id`` appears in the impression
298298
stream, the function rejects the ad. Otherwise the service shows the
299299
first acceptable ad to the user.

draft/use-cases/social-networking-updates-and-profiles.txt

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ Storing Updates and Profiles for Social Networking Sites
77
Overview
88
--------
99

10-
This document outlines the basic patterns and principless for using
10+
This document outlines the basic patterns and principles for using
1111
MongoDB as a persistent storage engine for a social networking
1212
website. In particular, this case study focuses on the task of storing
1313
and displaying user updates.
@@ -257,7 +257,7 @@ Consider the following features of this schema:
257257
.. not sure this collection is useful, instead just use the post collection.
258258
Posts should have an index on {user, time} and hence it is efficient to retrieve the wall.
259259
Also wall may be scrolled down to get further items.
260-
Dont think it's worth updating this document every time a user posts.
260+
Don't think it's worth updating this document every time a user posts.
261261

262262
The second dependent collection is is ``social.news``, which collects
263263
posts from people the user follows. These documents duplicate
@@ -530,7 +530,7 @@ The basic sequence of operations in the code above is the following:
530530
#. The post first saved into the "system of record," the ``social.post``
531531
collection.
532532

533-
#. The recipient's wall is updatd with the post.
533+
#. The recipient's wall is updated with the post.
534534

535535
#. Updates news feeds of everyone who is "circled" in the post.
536536

source/administration/monitoring.txt

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -242,7 +242,7 @@ there is a chance that a large number of requests are waiting for a
242242
lock. This indicates a possible concurrency issue that might effect
243243
performance.
244244

245-
If :status:`globalLock.toalTime` is high in context of
245+
If :status:`globalLock.totalTime` is high in context of
246246
:status:`uptime` then the database has existed in a lock state for a
247247
significant amount of time. If :status:`globalLock.ratio` is also
248248
high, MongoDB has likely been processing a large number of long

source/applications/database-references.txt

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -79,7 +79,7 @@ document:
7979
db.people.insert({
8080
"name": "Erin"
8181
"places_id": original_id
82-
"url": "bc.exmaple.net/Erin"
82+
"url": "bc.example.net/Erin"
8383
})
8484

8585
Then, when a query returns the document from the ``people`` collection
@@ -164,7 +164,7 @@ Support
164164
The :api:`DBRef <java/current/com/mongodb/DBRef.html>` class
165165
provides supports for DBRefs from Java.
166166

167-
**JavaScrpt**
167+
**JavaScript**
168168
The :program:`mongo` shell's :doc:`JavaScript </reference/javascript>`
169169
interface provides a DBRef.
170170

0 commit comments

Comments
 (0)