From 4b8fc3aad07d66dce37dd657c93ea227146af786 Mon Sep 17 00:00:00 2001 From: "Robert P. J. Day" Date: Sun, 25 Mar 2018 03:33:11 -0400 Subject: [PATCH] [FAB-9120] "key/value" -> "key-value" in some doc files Replace all instances of "key/value" in the docs with the accepted standard of "key-value" and, while there, might as well fix a few other grammar issues and typos on those very same lines. Change-Id: I4c4a0d0c192e212e86151894e7c463a53bd662f9 Signed-off-by: Robert P. J. Day --- docs/source/arch-deep-dive.rst | 10 +++++----- docs/source/build_network.rst | 2 +- docs/source/couchdb_as_state_database.rst | 4 ++-- docs/source/ledger.rst | 4 ++-- docs/source/write_first_app.rst | 4 ++-- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/docs/source/arch-deep-dive.rst b/docs/source/arch-deep-dive.rst index b4408aca15..5cd7a5897e 100644 --- a/docs/source/arch-deep-dive.rst +++ b/docs/source/arch-deep-dive.rst @@ -81,7 +81,7 @@ support for cross-chaincode transactions (post-v1 feature).* ^^^^^^^^^^^^ The latest state of the blockchain (or, simply, *state*) is modeled as a -versioned key/value store (KVS), where keys are names and values are +versioned key-value store (KVS), where keys are names and values are arbitrary blobs. These entries are manipulated by the chaincodes (applications) running on the blockchain through ``put`` and ``get`` KVS-operations. The state is stored persistently and updates to the @@ -467,11 +467,11 @@ As a result of the execution, the endorsing peer computes *read version dependencies* (``readset``) and *state updates* (``writeset``), also called *MVCC+postimage info* in DB language. -Recall that the state consists of key/value (k/v) pairs. All k/v entries -are versioned, that is, every entry contains ordered version -information, which is incremented every time when the value stored under +Recall that the state consists of key-value pairs. All key-value entries +are versioned; that is, every entry contains ordered version +information, which is incremented each time the value stored under a key is updated. The peer that interprets the transaction records all -k/v pairs accessed by the chaincode, either for reading or for writing, +key-value pairs accessed by the chaincode, either for reading or for writing, but the peer does not yet update its state. More specifically: - Given state ``s`` before an endorsing peer executes a transaction, diff --git a/docs/source/build_network.rst b/docs/source/build_network.rst index a417c191eb..ed5940f1b3 100644 --- a/docs/source/build_network.rst +++ b/docs/source/build_network.rst @@ -1039,7 +1039,7 @@ The output should display the two marbles owned by ``jerry``: Why CouchDB ------------- -CouchDB is a kind of NoSQL solution. It is a document oriented database where document fields are stored as key-value mpas. Fields can be either a simple key/value pair, list, or map. +CouchDB is a kind of NoSQL solution. It is a document-oriented database where document fields are stored as key-value maps. Fields can be either a simple key-value pair, list, or map. In addition to keyed/composite-key/key-range queries which are supported by LevelDB, CouchDB also supports full data rich queries capability, such as non-key queries against the whole blockchain data, since its data content is stored in JSON format and fully queryable. Therefore, CouchDB can meet chaincode, auditing, reporting requirements for many use cases that not supported by LevelDB. diff --git a/docs/source/couchdb_as_state_database.rst b/docs/source/couchdb_as_state_database.rst index 9e138860db..722ac30f69 100644 --- a/docs/source/couchdb_as_state_database.rst +++ b/docs/source/couchdb_as_state_database.rst @@ -4,9 +4,9 @@ CouchDB as the State Database State Database options ---------------------- -State database options include LevelDB and CouchDB. LevelDB is the default key/value state +State database options include LevelDB and CouchDB. LevelDB is the default key-value state database embedded in the peer process. CouchDB is an optional alternative external state database. -Like the LevelDB key/value store, CouchDB can store any binary data that is modeled in chaincode +Like the LevelDB key-value store, CouchDB can store any binary data that is modeled in chaincode (CouchDB attachment functionality is used internally for non-JSON binary data). But as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data. diff --git a/docs/source/ledger.rst b/docs/source/ledger.rst index 00cecfd7b8..cc951da669 100644 --- a/docs/source/ledger.rst +++ b/docs/source/ledger.rst @@ -38,7 +38,7 @@ therefore be regenerated from the chain at any time. The state database will aut recovered (or generated if needed) upon peer startup, before transactions are accepted. State database options include LevelDB and CouchDB. LevelDB is the default state database -embedded in the peer process and stores chaincode data as key/value pairs. CouchDB is an optional +embedded in the peer process and stores chaincode data as key-value pairs. CouchDB is an optional alternative external state database that provides addition query support when your chaincode data is modeled as JSON, permitting rich queries of the JSON content. See :doc:`couchdb_as_state_database` for more information on CouchDB. @@ -49,7 +49,7 @@ Transaction Flow At a high level, the transaction flow consists of a transaction proposal sent by an application client to specific endorsing peers. The endorsing peers verify the client signature, and execute a chaincode function to simulate the transaction. The output is the chaincode results, -a set of key/value versions that were read in the chaincode (read set), and the set of keys/values +a set of key-value versions that were read in the chaincode (read set), and the set of keys/values that were written in chaincode (write set). The proposal response gets sent back to the client along with an endorsement signature. diff --git a/docs/source/write_first_app.rst b/docs/source/write_first_app.rst index 7ec06e6fe0..1adee36ba3 100644 --- a/docs/source/write_first_app.rst +++ b/docs/source/write_first_app.rst @@ -188,7 +188,7 @@ Querying the Ledger ------------------- Queries are how you read data from the ledger. This data is stored as a series -of key/value pairs, and you can query for the value of a single key, multiple +of key-value pairs, and you can query for the value of a single key, multiple keys, or -- if the ledger is written in a rich data storage format like JSON -- perform complex searches against it (looking for all assets that contain certain keywords, for example). @@ -235,7 +235,7 @@ It should return something like this: These are the 10 cars. A black Tesla Model S owned by Adriana, a red Ford Mustang owned by Brad, a violet Fiat Punto owned by Pari, and so on. The ledger is -key/value based and in our implementation the key is ``CAR0`` through ``CAR9``. +key-value based and, in our implementation, the key is ``CAR0`` through ``CAR9``. This will become particularly important in a moment. Let's take a closer look at this program. Use an editor (e.g. atom or visual studio)