From 52655286690c8adc187d8c2fa4b4c3d45d2da2ff Mon Sep 17 00:00:00 2001 From: Maria Andersson Date: Thu, 4 Dec 2014 14:28:47 +0100 Subject: [PATCH] Remove trailing whitespaces This closes #8 Signed-off-by: Alexander Shorin --- src/docs/LICENSE | 4 +- src/docs/Makefile | 2 +- src/docs/NOTICE | 2 +- src/docs/ext/github.py | 8 +- src/docs/src/api/basics.rst | 2 +- src/docs/src/api/database/changes.rst | 2 +- src/docs/src/api/ddoc/common.rst | 2 +- src/docs/src/config/misc.rst | 26 +++--- src/docs/src/contributing.rst | 2 +- src/docs/src/couchapp/ddocs.rst | 4 +- src/docs/src/intro/api.rst | 124 ++++++++++++------------- src/docs/src/intro/security.rst | 14 +-- src/docs/src/intro/tour.rst | 2 +- src/docs/src/intro/why.rst | 6 +- src/docs/src/query-server/protocol.rst | 4 +- src/docs/templates/utilities.html | 2 +- 16 files changed, 103 insertions(+), 103 deletions(-) diff --git a/src/docs/LICENSE b/src/docs/LICENSE index eb3e753616c..ee1813ea47d 100644 --- a/src/docs/LICENSE +++ b/src/docs/LICENSE @@ -238,9 +238,9 @@ For the build/html/_static components: For the build/html/_static/jquery.js component: Copyright 2010, John Resig - + Copyright 2010, The Dojo Foundation - + Copyright 2012 jQuery Foundation and other contributors http://jquery.com/ diff --git a/src/docs/Makefile b/src/docs/Makefile index e0da59a9b99..85b9b10f46e 100644 --- a/src/docs/Makefile +++ b/src/docs/Makefile @@ -17,7 +17,7 @@ COUCHDOCSHA := $(shell git rev-parse --verify --short HEAD 2>/dev/null || echo COUCHRELEASE := $(COUCHVERSION)-git-$(COUCHDOCSHA) SOURCE := src/ PAPERSIZE := -D latex_paper_size=a4 -SPHINXFLAGS := -a -E -W -n -A local=1 $(PAPERSIZE) -d $(BUILDDIR)/doctree +SPHINXFLAGS := -a -E -W -n -A local=1 $(PAPERSIZE) -d $(BUILDDIR)/doctree SPHINXOPTS := $(SPHINXFLAGS) -D version=$(COUCHVERSION) -D release=$(COUCHRELEASE) $(SOURCE) all: distclean html pdf info man install clean diff --git a/src/docs/NOTICE b/src/docs/NOTICE index 9038e1967dc..40f42891176 100644 --- a/src/docs/NOTICE +++ b/src/docs/NOTICE @@ -7,7 +7,7 @@ The Apache Software Foundation (http://www.apache.org/). This product also includes the following third-party components: * Sphinx (http://sphinx-doc.org/) - + Copyright 2011, the Sphinx team * httpdomain.py (https://bitbucket.org/birkenfeld/sphinx-contrib/src/6a3a8ca714cfce957530890d0431d9a7b88c930f/httpdomain/sphinxcontrib/httpdomain.py?at=httpdomain-1.1.9) diff --git a/src/docs/ext/github.py b/src/docs/ext/github.py index 79bc1931619..312985c5dba 100644 --- a/src/docs/ext/github.py +++ b/src/docs/ext/github.py @@ -19,8 +19,8 @@ def get_github_url(app, view, path): view=view, branch=app.config.github_branch, path=path) - - + + def html_page_context(app, pagename, templatename, context, doctree): # base template for common sphinx pages like search or genindex # there is no need to provide github show/edit links for them @@ -35,8 +35,8 @@ def html_page_context(app, pagename, templatename, context, doctree): os.path.relpath(doctree.get('source'), app.builder.srcdir)) context['github_show_url'] = get_github_url(app, 'blob', path) context['github_edit_url'] = get_github_url(app, 'edit', path) - - + + def setup(app): app.add_config_value('github_project', '', True) app.add_config_value('github_branch', 'master', True) diff --git a/src/docs/src/api/basics.rst b/src/docs/src/api/basics.rst index d090a31e5ba..dfa9bfc7971 100644 --- a/src/docs/src/api/basics.rst +++ b/src/docs/src/api/basics.rst @@ -94,7 +94,7 @@ returned, listing the supported HTTP methods. For example: "error":"method_not_allowed", "reason":"Only GET,HEAD allowed" } - + The CouchDB design document API and the functions when returning HTML (for example as part of a show or list) enables you to include custom diff --git a/src/docs/src/api/database/changes.rst b/src/docs/src/api/database/changes.rst index 6e48f9b9baf..c892626f5cf 100644 --- a/src/docs/src/api/database/changes.rst +++ b/src/docs/src/api/database/changes.rst @@ -356,7 +356,7 @@ results. {"seq":6,"id":"updated","changes":[{"rev":"3-825cb35de44c433bfb2df415563a19de"}]} Obviously, `... tum tee tum ...` does not appear in the actual response, but -represents a long pause before the change with seq 6 occurred.   +represents a long pause before the change with seq 6 occurred. .. _Change Notifications in the book CouchDB The Definitive Guide: http://guide.couchdb.org/draft/notifications.html diff --git a/src/docs/src/api/ddoc/common.rst b/src/docs/src/api/ddoc/common.rst index 9f76e3a7fce..b3eecb6ff12 100644 --- a/src/docs/src/api/ddoc/common.rst +++ b/src/docs/src/api/ddoc/common.rst @@ -30,7 +30,7 @@ .. http:get:: /{db}/_design/{ddoc} :synopsis: Returns the design document - Returns the contents of the design document specified with the name of the design + Returns the contents of the design document specified with the name of the design document and from the specified database from the URL. Unless you request a specific revision, the latest revision of the document will always be returned. diff --git a/src/docs/src/config/misc.rst b/src/docs/src/config/misc.rst index e97575a6a94..d5c4fceda84 100644 --- a/src/docs/src/config/misc.rst +++ b/src/docs/src/config/misc.rst @@ -26,22 +26,22 @@ Configuration of Attachment Storage .. config:section:: attachments :: Configuration of Attachment Storage .. config:option:: compression_level - + Defines zlib compression level for the attachments from ``1`` (lowest, fastest) to ``9`` (highest, slowest). A value of ``0`` disables compression :: - + [attachments] compression_level = 8 - + .. config:option:: compressible_types - + Since compression is ineffective for some types of files, it is possible to let CouchDB compress only some types of attachments, specified by their MIME type:: - + [attachments] compressible_types = text/*, application/javascript, application/json, application/xml @@ -52,21 +52,21 @@ Statistic Calculation ===================== .. config:section:: stats :: Statistic Calculation - - + + .. config:option:: rate - + Rate of statistics gathering in milliseconds:: - + [stats] rate = 1000 - + .. config:option:: samples - + Samples are used to track the mean and standard value deviation within specified intervals (in seconds):: - + [stats] samples = [0, 60, 300, 900] @@ -187,7 +187,7 @@ UUIDs Configuration algorithm unless you have a specific need and take into account the likely need for compaction to re-balance the B-tree and reclaim wasted space. - + .. config:option:: utc_id_suffix :: UTC ID Suffix diff --git a/src/docs/src/contributing.rst b/src/docs/src/contributing.rst index edc20d58892..db2dc7f488d 100644 --- a/src/docs/src/contributing.rst +++ b/src/docs/src/contributing.rst @@ -112,7 +112,7 @@ but it includes some code listings. Let's mark them up. We'll turn:: Into:: .. code-block:: erlang - + ejson:encode(ejson:decode(<<"1.1">>)). <<"1.1000000000000000888">> diff --git a/src/docs/src/couchapp/ddocs.rst b/src/docs/src/couchapp/ddocs.rst index 4f4664a797c..a1d4f1175f2 100644 --- a/src/docs/src/couchapp/ddocs.rst +++ b/src/docs/src/couchapp/ddocs.rst @@ -477,7 +477,7 @@ events (documents with status `new`). Our filter function will look like this: } return true; // passed! } -  + Filter functions must return ``true`` if a document passed all defined rules. Now, if you apply this function to the changes feed it will emit only changes about "new mails":: @@ -614,7 +614,7 @@ by throwing one of two error objects: // user is not authorized to make the change but may re-authenticate throw({ unauthorized: 'Error message here.' }); - + // change is not allowed throw({ forbidden: 'Error message here.' }); diff --git a/src/docs/src/intro/api.rst b/src/docs/src/intro/api.rst index d68f6e683d2..83458a037e1 100644 --- a/src/docs/src/intro/api.rst +++ b/src/docs/src/intro/api.rst @@ -22,7 +22,7 @@ nitty-gritty and clever bits. We show you best practices and guide you around common pitfalls. We start out by revisiting the basic operations we ran in the previous document -:ref:`intro/tour`, looking behind the scenes. We also show what Futon needs to +:ref:`intro/tour`, looking behind the scenes. We also show what Futon needs to do behind its user interface to give us the nice features we saw earlier. This document is both an introduction to the core CouchDB API as well as a @@ -119,7 +119,7 @@ about how CouchDB works. CouchDB stores each database in a single file. Very simple. Let's create another database, this time with curl's ``-v`` (for "verbose") -option. The verbose option tells curl to show us not only the essentials -- +option. The verbose option tells curl to show us not only the essentials -- the HTTP response body -- but all the underlying request and response details:: curl -vX PUT http://127.0.0.1:5984/albums-backup @@ -174,8 +174,8 @@ The ``>`` means the line was sent to CouchDB verbatim (without the actual > PUT /albums-backup HTTP/1.1 This initiates an HTTP request. Its *method* is :method:`PUT`, the *URI* is -``/albums-backup``, and the HTTP version is ``HTTP/1.1``. There is also -``HTTP/1.0``, which is simpler in some cases, but for all practical reasons +``/albums-backup``, and the HTTP version is ``HTTP/1.1``. There is also +``HTTP/1.0``, which is simpler in some cases, but for all practical reasons you should be using ``HTTP/1.1``. Next, we see a number of *request headers*. These are used to provide @@ -189,8 +189,8 @@ The User-Agent header tells CouchDB which piece of client software is doing the HTTP request. We don't learn anything new: it's curl. This header is often useful in web development when there are known errors in client implementations that a server might want to prepare the response for. -It also helps to determine which platform a user is on. This information -can be used for technical and statistical reasons. For CouchDB, the +It also helps to determine which platform a user is on. This information +can be used for technical and statistical reasons. For CouchDB, the :header:`User-Agent` header is irrelevant. :: @@ -229,47 +229,47 @@ server. Or, if an error occurred, what kind of error. :rfc:`2616` (the HTTP 1.1 specification) defines clear behavior for response codes. CouchDB fully follows the RFC. -The :statuscode:`201` status code tells the client that the resource +The :statuscode:`201` status code tells the client that the resource the request was made against was successfully created. No surprise here, but if you remember that we got an error message when we tried to create this database twice, you now know that this response could include a different response code. Acting upon responses based on response codes is a common -practice. For example, all response codes of :statuscode:`400` or larger -tell you that some error occurred. If you want to shortcut your logic and -immediately deal with the error, you could just check a >= ``400`` response +practice. For example, all response codes of :statuscode:`400` or larger +tell you that some error occurred. If you want to shortcut your logic and +immediately deal with the error, you could just check a >= ``400`` response code. :: < Server: CouchDB (Erlang/OTP) -The :header:`Server` header is good for diagnostics. It tells us which -CouchDB version and which underlying Erlang version we are talking to. -In general, you can ignore this header, but it is good to know it's there if +The :header:`Server` header is good for diagnostics. It tells us which +CouchDB version and which underlying Erlang version we are talking to. +In general, you can ignore this header, but it is good to know it's there if you need it. :: < Date: Sun, 05 Jul 2009 22:48:28 GMT -The :header:`Date` header tells you the time of the server. Since client -and server time are not necessarily synchronized, this header is purely -informational. You shouldn't build any critical application logic on top +The :header:`Date` header tells you the time of the server. Since client +and server time are not necessarily synchronized, this header is purely +informational. You shouldn't build any critical application logic on top of this! :: < Content-Type: text/plain;charset=utf-8 -The :header:`Content-Type` header tells you which MIME type -the HTTP response body is and its encoding. We already know CouchDB returns -JSON strings. The appropriate :header:`Content-Type` header is -:mimetype:`application/json`. Why do we see :mimetype:`text/plain`? -This is where pragmatism wins over purity. Sending an -:mimetype:`application/json` :header:`Content-Type` header will make -a browser offer you the returned JSON for download instead of -just displaying it. Since it is extremely useful to be able to test CouchDB -from a browser, CouchDB sends a :mimetype:`text/plain` content type, so all +The :header:`Content-Type` header tells you which MIME type +the HTTP response body is and its encoding. We already know CouchDB returns +JSON strings. The appropriate :header:`Content-Type` header is +:mimetype:`application/json`. Why do we see :mimetype:`text/plain`? +This is where pragmatism wins over purity. Sending an +:mimetype:`application/json` :header:`Content-Type` header will make +a browser offer you the returned JSON for download instead of +just displaying it. Since it is extremely useful to be able to test CouchDB +from a browser, CouchDB sends a :mimetype:`text/plain` content type, so all browsers will display the JSON as text. .. note:: @@ -280,24 +280,24 @@ browsers will display the JSON as text. .. _JSONView: http://jsonview.com/ -Do you remember the :header:`Accept` request header and how it is set to +Do you remember the :header:`Accept` request header and how it is set to ``*/*`` to express interest in any MIME type? If you send ``Accept: -application/json`` in your request, CouchDB knows that you can deal with a pure -JSON response with the proper :header:`Content-Type` header and will +application/json`` in your request, CouchDB knows that you can deal with a pure +JSON response with the proper :header:`Content-Type` header and will use it instead of :mimetype:`text/plain`. :: < Content-Length: 12 -The :header:`Content-Length` header simply tells us how many bytes +The :header:`Content-Length` header simply tells us how many bytes the response body has. :: < Cache-Control: must-revalidate -This :header:`Cache-Control` header tells you, or any proxy server between +This :header:`Cache-Control` header tells you, or any proxy server between CouchDB and you, not to cache this response. :: @@ -372,14 +372,14 @@ CouchDB replies: .. code-block:: javascript {"ok":true,"id":"6e1295ed6c29495e54cc05947f18c8af","rev":"1-2902191555"} - -The curl command appears complex, but let's break it down. -First, ``-X PUT`` tells curl to make a :method:`PUT` request. -It is followed by the URL that specifies your CouchDB IP address and port. + +The curl command appears complex, but let's break it down. +First, ``-X PUT`` tells curl to make a :method:`PUT` request. +It is followed by the URL that specifies your CouchDB IP address and port. The resource part of the URL ``/albums/6e1295ed6c29495e54cc05947f18c8af`` -specifies the location of a document inside our albums database. -The wild collection of numbers and characters is a UUID. This UUID is your -document's ID. Finally, the ``-d`` flag tells curl to use the following +specifies the location of a document inside our albums database. +The wild collection of numbers and characters is a UUID. This UUID is your +document's ID. Finally, the ``-d`` flag tells curl to use the following string as the body for the :method:`PUT` request. The string is a simple JSON structure including ``title`` and ``artist`` attributes with their respective values. @@ -397,7 +397,7 @@ values. .. code-block:: javascript {"uuids":["6e1295ed6c29495e54cc05947f18c8af"]} - + Voilà, a UUID. If you need more than one, you can pass in the ``?count=10`` HTTP parameter to request 10 UUIDs, or really, any number you need. @@ -405,7 +405,7 @@ To double-check that CouchDB isn't lying about having saved your document (it usually doesn't), try to retrieve it by sending a GET request:: curl -X GET http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af - + We hope you see a pattern here. Everything in CouchDB has an address, a URI, and you use the different HTTP methods to operate on these URIs. @@ -427,10 +427,10 @@ Revisions --------- If you want to change a document in CouchDB, you don't tell it to go and find -a field in a specific document and insert a new value. Instead, you load -the full document out of CouchDB, make your changes in the JSON structure -(or object, when you are doing actual programming), and save the entire new -revision (or version) of that document back into CouchDB. Each revision is +a field in a specific document and insert a new value. Instead, you load +the full document out of CouchDB, make your changes in the JSON structure +(or object, when you are doing actual programming), and save the entire new +revision (or version) of that document back into CouchDB. Each revision is identified by a new ``_rev`` value. If you want to update or delete a document, CouchDB expects you to include @@ -450,23 +450,23 @@ CouchDB replies: .. code-block:: javascript {"error":"conflict","reason":"Document update conflict."} - + If you see this, add the latest revision number of your document to the JSON structure:: curl -X PUT http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af \ -d '{"_rev":"1-2902191555","title":"There is Nothing Left to Lose","artist":"Foo Fighters","year":"1997"}' -Now you see why it was handy that CouchDB returned that ``_rev`` when we made +Now you see why it was handy that CouchDB returned that ``_rev`` when we made the initial request. CouchDB replies: .. code-block:: javascript {"ok":true,"id":"6e1295ed6c29495e54cc05947f18c8af","rev":"2-8aff9ee9d06671fa89c99d20a4b3ae"} - -CouchDB accepted your write and also generated a new revision number. + +CouchDB accepted your write and also generated a new revision number. The revision number is the *MD5 hash* of the transport representation of a -document with an ``N-`` prefix denoting the number of times a document got +document with an ``N-`` prefix denoting the number of times a document got updated. This is useful for replication. See :ref:`replication/conflicts` for more information. @@ -574,17 +574,17 @@ the album artwork to the ``6e1295ed6c29495e54cc05947f18c8af`` document .. note:: - The ``--data-binary`` ``@`` option tells curl to read a file's contents into - the HTTP request body. We're using the ``-H`` option to tell CouchDB that - we're uploading a JPEG file. CouchDB will keep this information around and - will send the appropriate header when requesting this attachment; in case of - an image like this, a browser will render the image instead of offering you - the data for download. This will come in handy later. Note that you need - to provide the current revision number of the document you're attaching + The ``--data-binary`` ``@`` option tells curl to read a file's contents into + the HTTP request body. We're using the ``-H`` option to tell CouchDB that + we're uploading a JPEG file. CouchDB will keep this information around and + will send the appropriate header when requesting this attachment; in case of + an image like this, a browser will render the image instead of offering you + the data for download. This will come in handy later. Note that you need + to provide the current revision number of the document you're attaching the artwork to, just as if you would update the document. Because, after all, attaching some data is changing the document. -You should now see your artwork image if you point your browser to +You should now see your artwork image if you point your browser to http://127.0.0.1:5984/albums/6e1295ed6c29495e54cc05947f18c8af/artwork.jpg If you request the document again, you'll see a new member:: @@ -612,7 +612,7 @@ CouchDB replies: ``_attachments`` is a list of keys and values where the values are JSON objects containing the attachment metadata. ``stub=true`` tells us that this entry is -just the metadata. If we use the ``?attachments=true`` HTTP option when +just the metadata. If we use the ``?attachments=true`` HTTP option when requesting this document, we'd get a `Base64`_ encoded string containing the attachment data. @@ -626,7 +626,7 @@ Replication =========== CouchDB replication is a mechanism to synchronize databases. Much like `rsync`_ -synchronizes two directories locally or over a network, replication synchronizes +synchronizes two directories locally or over a network, replication synchronizes two databases locally or remotely. .. _rsync: http://en.wikipedia.org/wiki/Rsync @@ -681,7 +681,7 @@ easily): "session_id": "924e75e914392343de89c99d29d06671", "ok": true } - + CouchDB maintains a *session history* of replications. The response for a replication request contains the history entry for this *replication session*. It is also worth noting that the request for replication will stay open until @@ -692,7 +692,7 @@ replication replicates the database only as it was at the point in time when replication was started. So, any additions, modifications, or deletions subsequent to the start of replication will not be replicated. -We'll punt on the details again -- the ``"ok": true`` at the end tells us all +We'll punt on the details again -- the ``"ok": true`` at the end tells us all went well. If you now have a look at the albums-replica database, you should see all the documents that you created in the albums database. Neat, eh? @@ -732,7 +732,7 @@ is used by others:: -d '{"source":"http://example.org:5984/albums-replica","target":"albums"}' \ -H "Content-Type:application/json" -Finally, you can run remote replication, which is mostly useful for management +Finally, you can run remote replication, which is mostly useful for management operations:: curl -vX POST http://127.0.0.1:5984/_replicate \ @@ -770,7 +770,7 @@ Wrapping Up =========== This is still not the full CouchDB API, but we discussed the essentials in -great detail. We're going to fill in the blanks as we go. For now, we believe +great detail. We're going to fill in the blanks as we go. For now, we believe you're ready to start building CouchDB applications. .. seealso:: diff --git a/src/docs/src/intro/security.rst b/src/docs/src/intro/security.rst index 6887a013164..922c84599db 100644 --- a/src/docs/src/intro/security.rst +++ b/src/docs/src/intro/security.rst @@ -265,9 +265,9 @@ file and are wondering if regular users are also stored there. No, they are not. CouchDB has a special `authentication database`, named ``_users`` by default, that stores all registered users as JSON documents. -This special database is a `system database`, this means that while it shares +This special database is a `system database`, this means that while it shares the common :ref:`database API `, there are some -special security-related constraints applied. Below is listed how the +special security-related constraints applied. Below is listed how the `authentication database` is different from the other databases. - Only administrators may browse list of all documents @@ -380,8 +380,8 @@ CouchDB should respond with: {"ok":true,"name":"jan","roles":[]} -This means that the username was recognized and the password's hash matches -with the stored one. If we specify an incorrect login and/or password, CouchDB +This means that the username was recognized and the password's hash matches +with the stored one. If we specify an incorrect login and/or password, CouchDB will notify us with the following error message: .. code-block:: javascript @@ -392,15 +392,15 @@ will notify us with the following error message: Password Changing ================= -Let's define what is password changing from the point of view of CouchDB and +Let's define what is password changing from the point of view of CouchDB and the authentication database. Since "users" are "documents", this operation is just updating the document with a special field ``password`` which contains the *plain text password*. Scared? No need to be, the authentication database has a special internal hook on document update which looks for this field and replaces it with the *secured hash* depending on the chosen ``password_scheme``. -Summarizing the above process - we need to get the document's content, add -the ``password`` field with the new password in plain text and then store the +Summarizing the above process - we need to get the document's content, add +the ``password`` field with the new password in plain text and then store the JSON result to the authentication database. :: diff --git a/src/docs/src/intro/tour.rst b/src/docs/src/intro/tour.rst index 5d44d770443..08a9a6ef4dd 100644 --- a/src/docs/src/intro/tour.rst +++ b/src/docs/src/intro/tour.rst @@ -258,7 +258,7 @@ should look like :ref:`intro/tour-04`. You'll notice that the document's _rev has changed. We'll go into more detail about this in later documents, but for now, the important thing to note is that _rev acts like a safety feature when saving a document. As long as you -and CouchDB agree on the most recent _rev of a document, you can successfully +and CouchDB agree on the most recent _rev of a document, you can successfully save your changes. Futon also provides a way to display the underlying JSON data, diff --git a/src/docs/src/intro/why.rst b/src/docs/src/intro/why.rst index 8a76c48aba3..d9f0083c64f 100644 --- a/src/docs/src/intro/why.rst +++ b/src/docs/src/intro/why.rst @@ -32,7 +32,7 @@ to modularization and scalability. Relax ===== -If there's one word to describe CouchDB, it is *relax*. It is the byline +If there's one word to describe CouchDB, it is *relax*. It is the byline to CouchDB's official logo and when you start CouchDB, you see:: Apache CouchDB has started. Time to relax. @@ -310,6 +310,6 @@ less powerful than today's phones. Wrapping Up =========== -The next document :ref:`intro/consistency` further explores the distributed nature -of CouchDB. We should have given you enough bites to whet your interest. +The next document :ref:`intro/consistency` further explores the distributed nature +of CouchDB. We should have given you enough bites to whet your interest. Let's go! diff --git a/src/docs/src/query-server/protocol.rst b/src/docs/src/query-server/protocol.rst index c1f0b494a44..ec9bef020ab 100644 --- a/src/docs/src/query-server/protocol.rst +++ b/src/docs/src/query-server/protocol.rst @@ -108,7 +108,7 @@ The Query Server answers:: When creating or updating a view the Query Server gets sent the view function for evaluation. The Query Server should parse, compile and evaluate the function it receives to make it callable later. If this fails, the Query Server -returns an error. CouchDB might store several functions before sending in any +returns an error. CouchDB might store several functions before sending in any actual documents. CouchDB sends:: @@ -537,7 +537,7 @@ on three parts: There, we had made a big mistake: we had returned out result in a single message from the Query Server. That's ok when there are only a few rows in the -view result, but it's not acceptable for millions documents and millions view +view result, but it's not acceptable for millions documents and millions view rows Let's fix our list function and see the changes in communication:: diff --git a/src/docs/templates/utilities.html b/src/docs/templates/utilities.html index 22f4b8c651b..f49d584bbe3 100644 --- a/src/docs/templates/utilities.html +++ b/src/docs/templates/utilities.html @@ -19,4 +19,4 @@

Utilities

-{% endif %} \ No newline at end of file +{% endif %}