Skip to content
Permalink
Browse files
Fix typos and grammars
Co-authored-by: Jonathan Hall <flimzy@flimzy.com>
  • Loading branch information
2 people authored and nickva committed Apr 15, 2022
1 parent 27dda76 commit 05aaaca73263eaa07bdc911ef0644e14fa09d32a
Showing 22 changed files with 37 additions and 37 deletions.
@@ -154,13 +154,13 @@ def whitespace_committee(file):
in files. The documentation style guide says:
- There should be no trailing white space;
- More than one emtpy lines are not allowed and there shouldn't be such
- More than one empty line is not allowed and there shouldn't be such
at the end of file;
- The last line should ends with newline character
Additionally it alerts about for tabs if they were used instead of spaces.
Additionally it alerts about tabs if they were used instead of spaces.
TODO: check for indention
TODO: check for indentation
"""
error = prev = None
n = 0
@@ -246,7 +246,7 @@ def line_length_checker(file):
elif not line:
seen_emptyline = True

# So if we saw an empty line and here goes content without indention,
# So if we saw an empty line and here goes content without indentation,
# so it mostly have to sign about the end of our code block
# (if it ever occurs)
elif seen_emptyline and line and not line.startswith(" "):
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@@ -73,7 +73,7 @@ guarantees. The `Sequence` defined in the Terminology section above is totally
ordered across the entire cluster, and repeated calls to `_changes` on a
quiescent database will retrieve the same results in the same order. The
`Sequence` will still be encoded as a string, but as it's a more compact value
we propose to encode it in hexademical notation. These strings will sort
we propose to encode it in hexadecimal notation. These strings will sort
correctly, something that has not always been true in CouchDB 2.x.

## Data Model
@@ -122,7 +122,7 @@ In short, the operations in this subspace are
- doc insert: 0 read, 0 clear, 1 insert
- doc update: 0 read, 1 clear, 1 insert

## Handling of Unkown Commit Results
## Handling of Unknown Commit Results

When using versionstamped keys as proposed in this RFC one needs to pay
particular care to the degraded mode when FoundationDB responds to a transaction
@@ -133,7 +133,7 @@ this subspace are performed), so the risk for duplicate entries is indeed a
valid concern.

We can guard against creating duplicates in the "changes" subspace by having the
transaction that updates that subpsace also insert a KV into a dedicated
transaction that updates that subspace also insert a KV into a dedicated
"transaction ID" subspace specifically corresponding to this document update. If
the CouchDB layer receives a `commit_unknown_result` it can simply check for the
presence of the transaction ID in FoundationDB to determine whether the previous
@@ -155,7 +155,7 @@ the `BranchCount` for each row; if it's larger than 1, the client will need to
do a followup range request against the "revisions" subspace to retrieve the
additional revision identifiers to include in the response. A request with
`include_docs=true` will need to make a separate range request to the doc
storage subpsace to retrieve the body of each winning document revision.
storage subspace to retrieve the body of each winning document revision.

If a normal response to `_changes` cannot be delivered in a single transaction
the CouchDB layer should execute multiple transactions in series and stitch the
@@ -89,7 +89,7 @@ pack({"foo", "bar", "baz"}) = pack({123})
```

Clients SHOULD NOT submit objects containing duplicate keys, as CouchDB will
only preserve the last occurence of the key and will silently drop the other
only preserve the last occurrence of the key and will silently drop the other
occurrences. Similarly, clients MUST NOT rely on the ordering of keys within an
Object as this ordering will generally not be preserved by the database.

@@ -130,7 +130,7 @@ are baked into the key. The structure looks like this
et cetera
```

where `RevisionMetadata` includes at the minium an enum to enable schema
where `RevisionMetadata` includes at the minimum an enum to enable schema
evolution for subsequent changes to the document encoding structure, and
`NotDeleted` is `true` if this revision is a typical `deleted=false` revision,
and `false` if the revision is storing user-supplied data associated with the
@@ -119,7 +119,7 @@ that directly emits the format defined in the document storage RFC).
Assuming we can agree on a set of sizes and how they should be calculated, the
implementation will require two pieces: a single key for each size, mutated by
atomic operations, and a record of the size of each revision in the ?REVISIONS
subpsace so that a transaction can compute the delta for each document.
subspace so that a transaction can compute the delta for each document.

### Clustering

@@ -72,7 +72,7 @@ Adding `interactive: true` to the option field of an index will configure the in
}
```

Interactive views have two step process to being built. When an index is added to the database, a background job is created for the index to be built up to the change sequence, creation versionstamp, that the index was added at. Any new documents added after the index was added will be indexed in the transaction that the document is added to the database. If a query for an interative view is received before the background job is complete, CouchDB will wait until the background job is complete before serving the request.
Interactive views have two step process to being built. When an index is added to the database, a background job is created for the index to be built up to the change sequence, creation versionstamp, that the index was added at. Any new documents added after the index was added will be indexed in the transaction that the document is added to the database. If a query for an interactive view is received before the background job is complete, CouchDB will wait until the background job is complete before serving the request.

### Data model

@@ -118,7 +118,7 @@ Each field is defined as:
- `total_keys` is the number of keys emitted by a document
- `total_size` is the size of the key/values emitted by the document
- `unique_keys` is the unique keys emitted by the document
- `dupe_id` the duplication id to allow mutiple documents to emit a key/value
- `dupe_id` the duplication id to allow multiple documents to emit a key/value

The process flow for a document to be indexed in the background is as follows:

@@ -78,7 +78,7 @@ ExUnit shouldn't have these problems:
- performance tests
- property based tests

## Dissadvantages
## Disadvantages

- New language & tooling to learn
- We make Elixir required dependency (currently it is somewhat optional)
@@ -133,7 +133,7 @@ Following headers on the response would be supported

## Conventions

The conventions bellow are based on [conventions from opentracing](https://github.com/opentracing/specification/blob/main/semantic_conventions.md#standard-span-tags-and-log-fields).
The conventions below are based on [conventions from opentracing](https://github.com/opentracing/specification/blob/main/semantic_conventions.md#standard-span-tags-and-log-fields).
All tags are optional since it is just a recomendation from open tracing to hint visualization and filtering tools.

### Span tags
@@ -93,12 +93,12 @@ document are to be interpreted as described in

- The `first`/`next`/`last` keys in the response are represented as path which
includes the bookmark query key. This means the bookmark token size contributes
to total URI length and is subject to a max URL lenght (around 2000 characters).
to total URI length and is subject to a max URL length (around 2000 characters).
This means storing `keys` in a bookmark is not an option. For that reason
`POST` method is not supported when pagination is enabled
- Ideally we would want to signal (return 400) when number of rows returned from
streaming version of the endpoint goes over limit configured in `request_limit`.
However with streaming we've aready sent a return code.
However with streaming we've already sent a return code.

## Semantics of the implementation

@@ -140,7 +140,7 @@ document are to be interpreted as described in
}
```
- Every bookmark returned by `_all_docs/queries` and `{db}/_design/{ddoc}/_view/{view}/queries`
can be submited via separate request to `_all_docs` and `{db}/_design/{ddoc}/_view/{view}`
can be submitted via separate request to `_all_docs` and `{db}/_design/{ddoc}/_view/{view}`
correspondly.


@@ -44,7 +44,7 @@ in a set of sharded ETS tables. Each sharded ETS table has an associated
background process which periodically removes entries from there and calls the
index building API functions for each registered indexing backend.

In addition to buiding indices, the background index builder also cleanups up
In addition to building indices, the background index builder also cleanups up
stale index data. This is index data left behind after design documents have
been updated or deleted and the view signatures changed.

@@ -271,7 +271,7 @@ monitor the job status and re-create the job. In the current design,
`transient` jobs are persisted to FDB as `couch_jobs` records, and so would
survive node restarts. Also after transient jobs complete or failed,
they used to disappear immediately. This design proposes keeping them around
for a configurable emount of time to allow users to retrive their status via
for a configurable emount of time to allow users to retrieve their status via
`_scheduler/jobs/$id` API.

## Monitoring Endpoints
@@ -62,7 +62,7 @@ document are to be interpreted as described in
[NOTE]: # ( Headers and parameters accepted )
[NOTE]: # ( JSON in [if a PUT or POST type] )
[NOTE]: # ( JSON out )
[NOTE]: # ( Valid status codes and their defintions )
[NOTE]: # ( Valid status codes and their definitions )
[NOTE]: # ( A proposed Request and Response block )

## HTTP API deprecations
@@ -133,7 +133,7 @@ Internal Replication
======================
Purges are automatically replicated between replicas of the same database. Each
database has an internal purge tree that stores a certain number of the most
recent purges. This allows internal synchonization between replicas of the same
recent purges. This allows internal synchronization between replicas of the same
database.

External Replication
@@ -37,7 +37,7 @@ the nodes it is connected to and knows about.
"node1@xxx.xxx.xxx.xxx"]
}
* ``all_nodes`` are all the nodes thats this node knows about.
* ``all_nodes`` are all the nodes that this node knows about.
* ``cluster_nodes`` are the nodes that are connected to this node.

To add a node simply do:
@@ -160,7 +160,7 @@ Style Guidelines for this Documentation

When you make a change to the documentation, you should make sure that you
follow the style. Look through some files and you will see that the style is
quite straightforward. If you do not know if your formating is in compliance
quite straightforward. If you do not know if your formatting is in compliance
with the style, ask yourself the following question::

Is it needed for correct syntax?
@@ -165,7 +165,7 @@ equivalent JavaScript functions.

.. versionadded:: 2.2

Aproximates the number of distinct keys in a view index using a variant of the
Approximates the number of distinct keys in a view index using a variant of the
`HyperLogLog`_ algorithm. This algorithm enables an efficient, parallelizable
computation of cardinality using fixed memory resources. CouchDB has configured
the underlying data structure to have a relative error of ~2%.
@@ -58,7 +58,7 @@ all nodes are connected to all other nodes, in a mesh network configuration.
.. _cookie: http://erlang.org/doc/reference_manual/distributed.html

Every Erlang application running on that machine (such as CouchDB) then uses
automatically assigned ports for communciation with other nodes. Yes, this
automatically assigned ports for communication with other nodes. Yes, this
means random ports. This will obviously not work with a firewall, but it is
possible to force an Erlang application to use a specific port range.

@@ -217,7 +217,7 @@ locally on each node; if so, replace ``<server-IP|FQDN>`` below with ``127.0.0.1
# Create the admin user and password:
curl -X PUT http://<server-IP|FQDN>:5984/_node/_local/_config/admins/admin -d '"password"'
# Now, bind the clustered interface to all IP addresses availble on this machine
# Now, bind the clustered interface to all IP addresses available on this machine
curl -X PUT http://<server-IP|FQDN>:5984/_node/_local/_config/chttpd/bind_address -d '"0.0.0.0"'
# If not using the setup wizard / API endpoint, the following 2 steps are required:
@@ -101,7 +101,7 @@ The query server line protocol has changed for all functions except
:ref:`rereduce <qs/rereduce>`. This allows us to cache the entire design
document in the query server process, which results in faster performance for
common operations. It also gives more flexibility to query server
implementators and shouldn't require major changes in the future when adding
implementers and shouldn't require major changes in the future when adding
new query server features.

UTF8 JSON
@@ -343,7 +343,7 @@ View Server
* Improved view information objects.
* Bug fix for partial updates during view builds.
* Move query server to a design-doc based protocol.
* Use json2.js for JSON serialization for compatiblity with native JSON.
* Use json2.js for JSON serialization for compatibility with native JSON.
* Major refactoring of couchjs to lay the groundwork for disabling cURL
support. The new HTTP interaction acts like a synchronous XHR. Example usage
of the new system is in the JavaScript CLI test runner.
@@ -274,7 +274,7 @@ Other scheduling replicator improvements
* Network resource usage and performance was improved by
implementing a shared connection pool. This should help in cases
of a large number of connections to the same sources or
target. Previously connection pools were shared only withing a
target. Previously connection pools were shared only within a
single replication job.

* Improved request rate limit handling. Replicator requests will
@@ -364,7 +364,7 @@ The 2.1.0 release includes fixes for the following issues:
* :issue:`1447`: X-Couch-Update-NewRev header is missed if custom headers are
specified in response of _update handler (missed in 2.0 merge)
* :issue:`2731`: Authentication DB was not considered a system DB
* :issue:`3010`: (Superceded fix for replication exponential backoff)
* :issue:`3010`: (Superseded fix for replication exponential backoff)
* :issue:`3090`: Error when handling empty "Access-Control-Request-Headers"
header
* :issue:`3100`: Fix documentation on require_valid_user
@@ -390,7 +390,7 @@ The 2.1.0 release includes fixes for the following issues:
spawned process
* :issue:`3193`: fabric:open_revs returns multiple results when one of the
shards has stem_interactive_updates=false
* :issue:`3199`: Replicator VDU function doesn't acount for an already
* :issue:`3199`: Replicator VDU function doesn't account for an already
malformed document in replicator db
* :issue:`3202`: (mango) do not allow empty field names
* :issue:`3220`: Handle timeout in _revs_diff
@@ -162,7 +162,7 @@ Features
* :ghissue:`977`: When using ``COPY`` to copy a document, CouchDB no longer fails if
the new ID includes Unicode characters.
* :ghissue:`1095`: Recognize the environment variables ``ARGS_FILE``, ``SYSCONFIG_FILE``,
``COUCHDB_ARGS_FILE`` and ``COUCHDB_SYSCONFIG_FILE`` to overrride where CouchDB looks
``COUCHDB_ARGS_FILE`` and ``COUCHDB_SYSCONFIG_FILE`` to override where CouchDB looks
for the ``vm.args`` and ``sys.config`` files at startup.
* :ghissue:`1101`, :ghissue:`1425`: Mango can now be used to find conflicted documents
in a database by adding ``conflicts: true`` to a mango selector.
@@ -185,7 +185,7 @@ Performance

* :ghissue:`1409`: CouchDB no longer forces the TCP receive buffer to a fixed size
of 256KB, allowing the operating system to dynamically adjust the buffer size. This
can lead to siginificantly improved network performance when transferring large
can lead to significantly improved network performance when transferring large
attachments.
* :ghissue:`1423`: Mango selector matching now occurs at the shard level, reducing the
network traffic within a cluster for a mango query.
@@ -30,7 +30,7 @@ Features and Enhancements

* :ghissue:`3746`: ``couch_icu_driver`` collation driver has been
removed. ICU collation functionality is consolidated in the single
``couch_ejson_compare`` module. View performance might slighty
``couch_ejson_compare`` module. View performance might slightly
increase as there are less corner cases when the C collation driver
fails and falls back to Erlang.

0 comments on commit 05aaaca

Please sign in to comment.