Return-Path: X-Original-To: apmail-couchdb-commits-archive@www.apache.org Delivered-To: apmail-couchdb-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 70A8BDFB2 for ; Fri, 14 Sep 2012 10:17:38 +0000 (UTC) Received: (qmail 94092 invoked by uid 500); 14 Sep 2012 10:17:19 -0000 Delivered-To: apmail-couchdb-commits-archive@couchdb.apache.org Received: (qmail 93700 invoked by uid 500); 14 Sep 2012 10:17:15 -0000 Mailing-List: contact commits-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list commits@couchdb.apache.org Received: (qmail 91121 invoked by uid 99); 14 Sep 2012 10:17:01 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 14 Sep 2012 10:17:01 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id 54F0736871; Fri, 14 Sep 2012 10:17:00 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: dch@apache.org To: commits@couchdb.apache.org X-Mailer: ASF-Git Admin Mailer Subject: [41/49] import CouchBase docs Message-Id: <20120914101700.54F0736871@tyr.zones.apache.org> Date: Fri, 14 Sep 2012 10:17:00 +0000 (UTC) http://git-wip-us.apache.org/repos/asf/couchdb/blob/1055ea0e/share/docs/couchdb-manual-1.1/couchdb-configuration.xml ---------------------------------------------------------------------- diff --git a/share/docs/couchdb-manual-1.1/couchdb-configuration.xml b/share/docs/couchdb-manual-1.1/couchdb-configuration.xml new file mode 100644 index 0000000..ef1fd2b --- /dev/null +++ b/share/docs/couchdb-manual-1.1/couchdb-configuration.xml @@ -0,0 +1,328 @@ + + + + + Configuring CouchDB + + +   + + +
+ + CouchDB Configuration Files + + +   + + +
+ +
+ + Configuration File Locations + + + CouchDB reads files from the following locations, in the following + order. + + + + + + + PREFIX/default.ini + + + + + + PREFIX/default.d/* + + + + + + PREFIX/local.ini + + + + + + PREFIX/local.d/* + + + + + + + Settings in successive documents override the settings in earlier + entries. For example, setting the bind_address + parameter in local.ini would override any + setting in default.ini. + + + + + The default.ini file may be overwritten + during an upgrade or re-installation, so localised changes + should be made to the local.ini file or + files within the local.d directory. + + + +
+ +
+ + MochiWeb Server Options + + + Server options for the MochiWeb component of CouchDB can be added + to the configuration files. Settings should be added to the + server_options option of the + [httpd] section of + local.ini. For example: + + + +[httpd] +server_options = [{backlog, 128}, {acceptor_pool_size, 16}] + + +
+ +
+ + OS Daemons + + + CouchDB now supports starting external processes. The support is + simple and enables CouchDB to start each configured OS daemon. If + the daemon stops at any point, CouchDB will restart it (with + protection to ensure regularly failing daemons are not repeatedly + restarted). + + + + The daemon starting process is one-to-one; for each each + configured daemon in the configuration file, CouchDB will start + exactly one instance. If you need to run multiple instances, then + you must create separate individual configurations. Daemons are + configured within the [os_daemons] section of + your configuration file (local.ini). The + format of each configured daemon is: + + + +NAME = PATH ARGS + + + + Where NAME is an arbitrary (and unique) name to + identify the daemon; PATH is the full path to + the daemon to be executed; ARGS are any + required arguments to the daemon. + + + + For example: + + + +[os_daemons] +basic_responder = /usr/local/bin/responsder.js + + + + There is no interactivity between CouchDB and the running process, + but you can use the OS Daemons service to create new HTTP servers + and responders and then use the new proxy service to redirect + requests and output to the CouchDB managed service. For more + information on proxying, see + . For + further background on the OS Daemon service, see + CouchDB + Externals API + + +
+ +
+ + Update Notifications + + +   + + +
+ +
+ + Socket Options Configuration Setting + + + The socket options for the listening socket in CouchDB can now be + set within the CouchDB configuration file. The setting should be + added to the [httpd] section of the file using + the option name socket_options. The + specification is as a list of tuples. For example: + + + +[httpd] +socket_options = [{recbuf, 262144}, {sndbuf, 262144}, {nodelay, true}] + + + + The options supported are a subset of full options supported by + the TCP/IP stack. A list of the supported options are provided in + the + Erlang + inet documentation. + + +
+ +
+ + <literal>vhosts</literal> definitions + + + Similar to the rewrites section of a _design + document, the vhosts system uses variables in + the form of :varname or wildcards in the form of asterisks. The + variable results can be output into the resulting path as they are + in the rewriter. + + +
+ +
+ + Configuring SSL Network Sockets + + + SSL configuration in CouchDB was designed to be as easy as + possible. All you need is two files; a certificate and a private + key. If you bought an official SSL certificate from a certificate + authority, both should be in your possession already. + + + + If you just want to try this out and don't want to pay anything + upfront, you can create a self-signed certificate. Everything will + work the same, but clients will get a warning about an insecure + certificate. + + + + You will need the OpenSSL command line tool installed. It probably + already is. + + + +shell> mkdir cert && cd cert +shell> openssl genrsa > privkey.pem +shell> openssl req -new -x509 -key privkey.pem -out mycert.pem -days 1095 +shell> ls +mycert.pem privkey.pem + + + + Now, you need to edit CouchDB's configuration, either by editing + your local.ini file or using the + /_config API calls or the configuration screen + in Futon. Here is what you need to do in + local.ini, you can infer what needs doing in + the other places. + + + + Be sure to make these edits. Under [daemons] + you should see: + + + +; enable SSL support by uncommenting the following line and supply the PEM's below. +; the default ssl port CouchDB listens on is 6984 +;httpsd = {couch_httpd, start_link, [https]} + + + + Here uncomment the last line: + + + +httpsd = {couch_httpd, start_link, [https]} + + + + Next, under [ssl] you will see: + + + +;cert_file = /full/path/to/server_cert.pem +;key_file = /full/path/to/server_key.pem + + + + Uncomment and adjust the paths so it matches your system's paths: + + + +cert_file = /home/jan/cert/mycert.pem +key_file = /home/jan/cert/privkey.pem + + + + For more information please read + http://www.openssl.org/docs/HOWTO/certificates.txt. + + + + Now start (or restart) CouchDB. You should be able to connect to + it using HTTPS on port 6984: + + + +shell> curl https://127.0.0.1:6984/ +curl: (60) SSL certificate problem, verify that the CA cert is OK. Details: +error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed +More details here: http://curl.haxx.se/docs/sslcerts.html + +curl performs SSL certificate verification by default, using a "bundle" +of Certificate Authority (CA) public keys (CA certs). If the default +bundle file isn't adequate, you can specify an alternate file +using the --cacert option. +If this HTTPS server uses a certificate signed by a CA represented in +the bundle, the certificate verification probably failed due to a +problem with the certificate (it might be expired, or the name might +not match the domain name in the URL). +If you'd like to turn off curl's verification of the certificate, use +the -k (or --insecure) option. + + + + Oh no what happened?! — Remember, clients will notify their + users that your certificate is self signed. + curl is the client in this case and it notifies + you. Luckily you trust yourself (don't you?) and you can specify + the option as the message reads: + + + +shell> curl -k https://127.0.0.1:6984/ +{"couchdb":"Welcome","version":"1.1.0"} + + +
+ + + +
http://git-wip-us.apache.org/repos/asf/couchdb/blob/1055ea0e/share/docs/couchdb-manual-1.1/couchdb-dbmaint.xml ---------------------------------------------------------------------- diff --git a/share/docs/couchdb-manual-1.1/couchdb-dbmaint.xml b/share/docs/couchdb-manual-1.1/couchdb-dbmaint.xml new file mode 100644 index 0000000..bdd4184 --- /dev/null +++ b/share/docs/couchdb-manual-1.1/couchdb-dbmaint.xml @@ -0,0 +1,15 @@ + + +%every.entities; +]> + + + Database Maintenance + + +   + + + http://git-wip-us.apache.org/repos/asf/couchdb/blob/1055ea0e/share/docs/couchdb-manual-1.1/couchdb-features.xml ---------------------------------------------------------------------- diff --git a/share/docs/couchdb-manual-1.1/couchdb-features.xml b/share/docs/couchdb-manual-1.1/couchdb-features.xml new file mode 100644 index 0000000..3c7edc3 --- /dev/null +++ b/share/docs/couchdb-manual-1.1/couchdb-features.xml @@ -0,0 +1,301 @@ + + +%every.entities; +]> + + + Features and Functionality + + +   + + +
+ + HTTP Range Requests + + + HTTP allows you to specify byte ranges for requests. This allows + the implementation of resumable downloads and skippable audio and + video streams alike. The following example uses a text file to + make the range request process easier. + + + +shell> cat file.txt +My hovercraft is full of eels! + + + + Uploading this as an attachment to a text + database using curl: + + + +shell> curl -X PUT http://127.0.0.1:5984/test/doc/file.txt \ + -H "Content-Type: application/octet-stream" -d@file.txt +{"ok":true,"id":"doc","rev":"1-287a28fa680ae0c7fb4729bf0c6e0cf2"} + + + + Requesting the whole file works as normal: + + + +shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt +My hovercraft is full of eels! + + + + But to retrieve only the first 13 bytes using + curl: + + + +shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt -H "Range: bytes=0-12" +My hovercraft + + + + HTTP supports many ways to specify single and even multiple byte + rangers. See + RFC + 2616. + + + + + Databases that have been created with CouchDB 1.0.2 or earlier + will support range requests in 1.1.0, but they are using a + less-optimal algorithm. If you plan to make heavy use of this + feature, make sure to compact your database with CouchDB 1.1.0 + to take advantage of a better algorithm to find byte ranges. + + + +
+ +
+ + HTTP Proxying + + + The HTTP proxy feature makes it easy to map and redirect different + content through your CouchDB URL. The proxy works by mapping a + pathname and passing all content after that prefix through to the + configured proxy address. + + + + Configuration of the proxy redirect is handled through the + [httpd_global_handlers] section of the CouchDB + configuration file (typically local.ini). The + format is: + + + +[httpd_global_handlers] +PREFIX = {couch_httpd_proxy, handle_proxy_req, <<"DESTINATION">>} + + + + Where: + + + + + + + PREFIX + + + + Is the string that will be matched. The string can be any + valid qualifier, although to ensure that existing database + names are not overridden by a proxy configuration, you can use + an underscore prefix. + + + + + + DESTINATION + + + + The fully-qualified URL to which the request should be sent. + The destination must include the http + prefix. The content is used verbatim in the original request, + so you can also forward to servers on different ports and to + specific paths on the target host. + + + + + + + The proxy process then translates requests of the form: + + + +http://couchdb:5984/PREFIX/path + + + + To: + + + +DESTINATION/path + + + + + Everything after PREFIX including the + required forward slash will be appended to the + DESTINATION. + + + + + The response is then communicated back to the original client. + + + + For example, the following configuration: + + + +>}]]> + + + + Would forward all requests for + http://couchdb:5984/_google to the Google + website. + + + + The service can also be used to forward to related CouchDB + services, such as Lucene: + + + + >}]]> + + + + + The proxy service is basic. If the request is not identified by + the DESTINATION, or the remainder of the + PATH specification is incomplete, the + original request URL is interpreted as if the + PREFIX component of that URL does not exist. + + + + For example, requesting + http://couchdb:5984/_intranet/media when + /media on the proxy destination does not + exist, will cause the request URL to be interpreted as + http://couchdb:5984/media. Care should be + taken to ensure that both requested URLs and destination URLs + are able to cope + + + +
+ +
+ + CommonJS support for map functions + + + CommonJS support allows you to use CommonJS notation inside + map and reduce + functions, but only of libraries that are stored inside the views + part of the design doc. + + + + So you could continue to access CommonJS code in design_doc.foo, + from your list functions etc, but we'd add the ability to require + CommonJS modules within map and reduce, but only from + design_doc.views.lib. + + + + There's no worry here about namespace collisions, as Couch just + plucks views.*.map and + views.*.reduce out of the design doc. So you + could have a view called lib if you wanted, and + still have CommonJS stored in views.lib.sha1 + and views.lib.stemmer if you wanted. + + + + The implementation is simplified by enforcing that CommonJS + modules to be used in map functions be + stored in views.lib. + + + + A sample design doc (taken from the test suite in Futon) is below: + + + +{ + "views" : { + "lib" : { + "baz" : "exports.baz = 'bam';", + "foo" : { + "zoom" : "exports.zoom = 'yeah';", + "boom" : "exports.boom = 'ok';", + "foo" : "exports.foo = 'bar';" + } + }, + "commonjs" : { + "map" : "function(doc) { emit(null, require('views/lib/foo/boom').boom)}" + } + }, + "_id" : "_design/test" +} + + + + The require() statement is relative to the + design document, but anything loaded form outside of + views/lib will fail. + + +
+ +
+ + Granular ETag support + + + ETags have been assigned to a map/reduce group (the collection of + views in a single design document). Any change to any of the + indexes for those views would generate a new ETag for all view + URL's in a single design doc, even if that specific view's results + had not changed. + + + + In CouchDB 1.1 each _view URL has it's own ETag + which only gets updated when changes are made to the database that + effect that index. If the index for that specific view does not + change, that view keeps the original ETag head (therefore sending + back 304 Not Modified more often). + + +
+ +
http://git-wip-us.apache.org/repos/asf/couchdb/blob/1055ea0e/share/docs/couchdb-manual-1.1/couchdb-introduction.xml ---------------------------------------------------------------------- diff --git a/share/docs/couchdb-manual-1.1/couchdb-introduction.xml b/share/docs/couchdb-manual-1.1/couchdb-introduction.xml new file mode 100644 index 0000000..15c123b --- /dev/null +++ b/share/docs/couchdb-manual-1.1/couchdb-introduction.xml @@ -0,0 +1,578 @@ + + +%every.entities; +]> + + + Introduction + + + There are two interfaces to CouchDB, the built-in + Futon web-based interface and the CouchDB API accessed through the + HTTP REST interface. The former is the simplest way to view and + monitor your CouchDB installation and perform a + number of basic database and system operations. More information on + using the Futon interface can be found in + . + + + + The primary way to interact with the CouchDB API is to use a client + library or other interface that provides access to the underlying + functionality through your chosen language or platform. However, + since the API is supported through HTTP REST, you can interact with + your CouchDB with any solution that supports the + HTTP protocol. + + + + There are a number of different tools that talk the HTTP protocol + and allow you to set and configure the necessary information. One + tool for this that allows for access from the command-line is + curl. See + . + + +
+ + Using Futon + + + Futon is a native web-based interface built into CouchDB. It provides a basic interface to the majority of the + functionality, including the ability to create, update, delete and + view documents and views, provides access to the configuration + parameters, and an interface for initiating replication. + + + + The default view is the Overview page which + provides you with a list of the databases. The basic structure of + the page is consistent regardless of the section you are in. The + main panel on the left provides the main interface to the + databases, configuration or replication systems. The side panel on + the right provides navigation to the main areas of Futon + interface: + + +
+ + Futon Overview + + + + + + + + + + + + Futon Overview + + + + + +
+ + + The main sections are: + + + + + + + Overview + + + + The main overview page, which provides a list of the databases + and provides the interface for querying the database and + creating and updating documents. See + . + + + + + + Configuration + + + + An interface into the configuration of your CouchDB installation. The interface allows you to edit the + different configurable parameters. For more details on + configuration, see + . + + + + + + Replicator + + + + An interface to the replication system, enabling you to + initiate replication between local and remote databases. See + . + + + + + + Status + + + + Displays a list of the running background tasks on the server. + Background tasks include view index building, compaction and + replication. The Status page is an + interface to the + Active + Tasks API call. See + . + + + + + + Verify Installation + + + + The Verify Installation allows you to + check whether all of the components of your CouchDB installation are correctly installed. + + + + + + Test Suite + + + + The Test Suite section allows you to + run the built-in test suite. This executes a number of test + routines entirely within your browser to test the API and + functionality of your CouchDB installation. If + you select this page, you can run the tests by using the + Run All button. This will execute all + the tests, which may take some time. + + + + + +
+ + Managing Databases and Documents + + + You can manage databases and documents within Futon using the + main Overview section of the Futon + interface. + + + + To create a new database, click the Create Database + &ellipsis; button. You will be prompted for the + database name, as shown in the figure below. + + +
+ + Creating a Database + + + + + + + + + + + + Creating a Database + + + + + +
+ + + Once you have created the database (or selected an existing + one), you will be shown a list of the current documents. If you + create a new document, or select an existing document, you will + be presented with the edit document display. + + + + Editing documents within Futon requires selecting the document + and then editing (and setting) the fields for the document + individually before saving the document back into the database. + + + + For example, the figure below shows the editor for a single + document, a newly created document with a single ID, the + document _id field. + + +
+ + Editing a Document + + + + + + + + + + + + Editing a Document + + + + + +
+ + + To add a field to the document: + + + + + + + Click Add Field. + + + + + + In the fieldname box, enter the name of the field you want + to create. For example, company. + + + + + + Click the green tick next to the field name to confirm the + field name change. + + + + + + Double-click the corresponding Value + cell. + + + + + + Enter a company name, for example Example. + + + + + + Click the green tick next to the field value to confirm the + field value. + + + + + + The document is still not saved as this point. You must + explicitly save the document by clicking the Save + Document button at the top of the page. This + will save the document, and then display the new document + with the saved revision information (the + _rev field). + + +
+ + Edited Document + + + + + + + + + + + + Edited Document + + + + + +
+
+ +
+ + + The same basic interface is used for all editng operations + within Futon. You must rememmbr to save the + individual element (fieldname, value) using the green tick + button, before then saving the document. + + +
+ +
+ + Configuring Replication + + + When you click the Replicator option + within the Tools menu you are presented + with the Replicator screen. This allows you to start replication + between two databases by filling in or select the appropriate + options within the form provided. + + +
+ + Replication Form + + + + + + + + + + + + Replication Form + + + + + +
+ + + To start a replication process, either the select the local + database or enter a remote database name into the corresponding + areas of the form. Replication occurs from the database on the + left to the database on the right. + + + + If you are specifying a remote database name, you must specify + the full URL of the remote database (including the host, port + number and database name). If the remote instance requires + authentication, you can specify the username and password as + part of the URL, for example + http://username:pass@remotehost:5984/demo. + + + + To enable continuous replication, click the + Continuous checkbox. + + + + To start the replication process, click the + Replicate button. The replication process + should start and will continue in the background. If the + replication process will take a long time, you can monitor the + status of the replication using the + Status option under the + Tools menu. + + + + Once replication has been completed, the page will show the + information returned when the replication process completes by + the API. + + + + The Replicator tool is an interface to the + underlying replication API. For more information, see + . + For more information on replication, see + . + + +
+ +
+ +
+ + Using <command>curl</command> + + + The curl utility is a command line tool + available on Unix, Linux, Mac OS X and Windows and many other + platforms. curl provides easy access to the + HTTP protocol (among others) directly from the command-line and is + therefore an ideal way of interacting with CouchDB + over the HTTP REST API. + + + + For simple GET requests you can supply the URL + of the request. For example, to get the database information: + + + +shell> curl http://127.0.0.1:5984 + + + + This returns the database information (formatted in the output + below for clarity): + + + +{ + "modules" : { + "geocouch" : "7fd793c10f3aa667a1088a937398bc5b51472b7f" + }, + "couchdb" : "Welcome", + "version" : "1.1.0", +} + + + + + For some URLs, especially those that include special characters + such as ampersand, exclamation mark, or question mark, you + should quote the URL you are specifying on the command line. For + example: + + + +shell> curl 'http://couchdb:5984/_uuids?count=5' + + + + + You can explicitly set the HTTP command using the + command line option. For example, when + creating a database, you set the name of the database in the URL + you send using a PUT request: + + + +shell> curl -X PUT http://127.0.0.1:5984/demo +{"ok":true} + + + + But to obtain the database information you use a + GET request (with the return information + formatted for clarity): + + + +shell> curl -X GET http://127.0.0.1:5984/demo +{ + "compact_running" : false, + "doc_count" : 0, + "db_name" : "demo", + "purge_seq" : 0, + "committed_update_seq" : 0, + "doc_del_count" : 0, + "disk_format_version" : 5, + "update_seq" : 0, + "instance_start_time" : "1306421773496000", + "disk_size" : 79 +} + + + + For certain operations, you must specify the content type of + request, which you do by specifying the + Content-Type header using the + command-line option: + + + +shell> curl -H 'Content-type: application/json' http://127.0.0.1:5984/_uuids + + + + You can also submit 'payload' data, that is, data in the body of + the HTTP request using the option. This is + useful if you need to submit JSON structures, for example document + data, as part of the request. For example, to submit a simple + document to the demo database: + + + +shell> curl -H 'Content-type: application/json' \ + -X POST http://127.0.0.1:5984/demo \ + -d '{"company": "Example, Inc."}' +{"ok":true,"id":"8843faaf0b831d364278331bc3001bd8", + "rev":"1-33b9fbce46930280dab37d672bbc8bb9"} + + + + In the above example, the argument after the + option is the JSON of the document we want to submit. + + + + The document can be accessed by using the automatically generated + document ID that was returned: + + + +shell> curl -X GET http://127.0.0.1:5984/demo/8843faaf0b831d364278331bc3001bd8 +{"_id":"8843faaf0b831d364278331bc3001bd8", + "_rev":"1-33b9fbce46930280dab37d672bbc8bb9", + "company":"Example, Inc."} + + + + The API samples in the show + the HTTP command, URL and any payload information that needs to be + submitted (and the expected return value). All of these examples + can be reproduced using curl with the + command-line examples shown above. + + +
+ +