{"id":7470,"date":"2015-09-28T21:11:24","date_gmt":"2015-09-28T18:11:24","guid":{"rendered":"http:\/\/www.webcodegeeks.com\/?p=7470"},"modified":"2018-01-05T16:53:10","modified_gmt":"2018-01-05T14:53:10","slug":"couchdb-basics-and-operations","status":"publish","type":"post","link":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/","title":{"rendered":"CouchDB: Basics and Operations"},"content":{"rendered":"

This article is part of our Academy Course titled CouchDB \u2013 Database for the Web<\/a>.<\/p>\n

This is a hands-on course on CouchDB. You will learn how to install and configure CouchDB and how to perform common operations with it. Additionally, you will build an example application from scratch and then finish the course with more advanced topics like scaling, replication and load balancing. Check it out here<\/a>!<\/em>
\n 
\n 
\n 
\n 
\n[ulp id=’tgm4cmEWcKUikZNn’]<\/p>\n

\n

Table Of Contents<\/h4>\n
\n
1. Introduction<\/a><\/dt>\n
2. Futon<\/a><\/dt>\n
\n
\n
2.1 Managing Databases and Documents<\/a><\/dt>\n
2.2 Configuring Replication<\/a><\/dt>\n<\/dl>\n<\/dd>\n
3. CRUD Operations<\/a><\/dt>\n
\n
\n
3.1 Documents<\/a><\/dt>\n<\/dl>\n<\/dd>\n
4. Common HTTP operations<\/a><\/dt>\n
\n
\n
4.1 Databases<\/a><\/dt>\n
4.2 Documents<\/a><\/dt>\n
4.3 Attachments<\/a><\/dt>\n
4.4 Replication<\/a><\/dt>\n<\/dl>\n<\/dd>\n
5. JSON<\/a><\/dt>\n
\n
\n
5.1 Data Types<\/a><\/dt>\n
5.2 Numbers<\/a><\/dt>\n
5.3 Strings<\/a><\/dt>\n
5.4 Booleans<\/a><\/dt>\n<\/dl>\n<\/dd>\n
6. Documents<\/a><\/dt>\n
\n
\n
6.1 Special Fields<\/a><\/dt>\n
6.2 Document IDs<\/a><\/dt>\n
6.3 Working With Documents Over HTTP<\/a><\/dt>\n<\/dl>\n<\/dd>\n
7. Revisions<\/a><\/dt>\n
\n
\n
7.1 Accessing Previous Revisions<\/a><\/dt>\n
7.2 HEAD<\/a><\/dt>\n
7.3 PUT<\/a><\/dt>\n
7.4 POST<\/a><\/dt>\n
7.5 DELETE<\/a><\/dt>\n
7.6 COPY<\/a><\/dt>\n
7.7 All Documents<\/a><\/dt>\n<\/dl>\n<\/dd>\n
8. Replication<\/a><\/dt>\n<\/dl>\n<\/div>\n

<\/a>1. Introduction<\/h2>\n

As we saw in our introductory lesson<\/a>, Apache CouchDB is an open source NoSQL database that uses JSON to store data, JavaScript as its query language and HTTP for an API. In CouchDB, each database is actually a collection of documents. Each document maintains its own data and a self-contained schema. An application may access multiple databases on different servers and Document metadata contain revision information in order to make merging possible in case the databases get disconnected.<\/p>\n

In CouchDB, all operations have a unique URI that gets exposed via HTTP. The REST APIs use the typical HTTP methods POST, GET, PUT and DELETE for the four basic CRUD (Create, Read, Update, Delete) operations on all resources. Finally, Futon is CouchDB’s web-based administration console. Let’s see more details for those components.<\/p>\n

<\/a>2. Futon<\/h2>\n

Futon will can be accessed by a browser via the following address: http:\/\/localhost:5984\/_utils\/<\/a><\/p>\n

The main overview page provides a list of the databases and provides the interface for querying the database and creating and updating documents.<\/p>\n

The main sections in Futon are:<\/p>\n

    \n
  1. Configuration:<\/strong> An interface into the configuration of Wer CouchDB installation. The interface allows us to edit the different configurable parameters.<\/li>\n
  2. Replicator:<\/strong> An interface to the replication system, enabling us to initiate replication between local and remote databases.<\/li>\n
  3. Status:<\/strong> 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.<\/li>\n
  4. Verify Installation:<\/strong> The Verify Installation allows us to check whether all of the components of CouchDB installation are correctly installed.<\/li>\n
  5. Test Suite:<\/strong> The Test Suite section allows us to run the built-in test suite. This executes a number of test routines entirely within browser to test the API and functionality of CouchDB installation.<\/li>\n<\/ol>\n

    <\/a>2.1 Managing Databases and Documents<\/h3>\n

    We can manage databases and documents within Futon using the main Overview section of the Futon interface.<\/p>\n

    To create a new database, click the Create Database Ellipsis button. We will be prompted for the database name, as shown in the figure below.<\/p>\n

    \"Create<\/a>
    Create CouchDB Database<\/figcaption><\/figure>\n

    Type the database name (i.e. ‘blog’ here) in the textbox that we want to create.<\/p>\n

    Once we have created the database (or selected an existing one), we will be shown a list of the current documents. If we create a new document, or select an existing document, we will be presented with the edit document display.<\/p>\n

    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.<\/p>\n

    For example, the figure below shows the editor for a single document, a newly created document with a single ID, the document _id field (click on the image to show in full size).<\/p>\n

    \"New<\/a>
    New document<\/figcaption><\/figure>\n

    To add a field to the document:<\/p>\n

      \n
    1. Click Add Field.<\/li>\n
    2. In the fieldname box, enter the name of the field. For example, \u201cblogger_name\u201d.<\/li>\n
    3. Click the green tick next to the field name to confirm the field name change.<\/li>\n

       
      \n

      \"Changing<\/a>
      Changing a field name<\/figcaption><\/figure><\/p>\n
    4. Double-click the corresponding Value cell.<\/li>\n
    5. Enter a company name, for example \u201cjohn\u201d.<\/li>\n

       
      \n

      \"Field<\/a>
      Field name changed<\/figcaption><\/figure><\/p>\n
    6. Click the green tick next to the field value to confirm the field value.<\/li>\n
    7. We 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). (Click on image to show in full size)<\/li>\n

       
      \n

      \"Document<\/a>
      Document changes<\/figcaption><\/figure>\n<\/ol>\n

      <\/a>2.2 Configuring Replication<\/h3>\n

      When we click the Replicator option within the Tools menu we are presented with the Replicator screen. This allows us to start replication between two databases by filling in or select the appropriate options within the form provided.<\/p>\n

      For example, let’s say we have another database ‘test’. So the list of databases are the following:<\/p>\n

      \"Databases<\/a>
      Databases Overview<\/figcaption><\/figure>\n

      Now we are going to replicate database from ‘blog’ to ‘test’.<\/p>\n

      To do that, click on the ‘Replicator’ on the right side panel.<\/p>\n

      To start the replication process, either select the local database or enter a remote database name into the corresponding areas of the form. The replication occurs from the database on the left to the database on the right.<\/p>\n

      If we are specifying a remote database name, we must specify the full URL of the remote database (including the host, port number and database name). If the remote instance requires authentication, we can specify the username and password as part of the URL, for example http:\/\/username:pass@remotehost:5984\/blog. (Click on image to show in full size)<\/p>\n

      \"Remote<\/a>
      Remote CouchDB Replication<\/figcaption><\/figure>\n

      To enable continuous replication, click the Continuous checkbox. Click on the ‘Replicate’ button.<\/p>\n

      The replication process should start and will continue in the background. If the replication process takes a long time, we can monitor the status of the replication using the Status option under the Tools menu.<\/p>\n

      Once the replication has been completed, the page will show the information using the CouchDB API.<\/p>\n

      The result will be shown like in the following image (Click on image to show in full size):<\/p>\n

      \"Replication<\/a>
      Replication Result<\/figcaption><\/figure>\n

      If we now open the ‘test’ database, we will find an exact replica of the ‘blog’ database:<\/p>\n

      \"Successful<\/a>
      Successful Replication<\/figcaption><\/figure>\n

      <\/a>3. CRUD Operations<\/h2>\n

      Next, we will have a quick look at CouchDB\u2019s bare-bones Application Programming Interface (API) by using the command-line utility “curl”. It gives us control over raw HTTP requests and we can see exactly what is going on the database.<\/p>\n

      Make sure CouchDB is still running and then from the command line execute the following:<\/p>\n

      curl http:\/\/127.0.0.1:5984\/<\/pre>\n
      This issues a GET request to the newly installed CouchDB instance. The reply should look something like:<\/p>\n
      {\"couchdb\":\"Welcome\",\"version\":\"1.0.1\"}<\/pre>\n
      Next, we can get a list of the existing databases:<\/p>\n
      curl -X GET http:\/\/127.0.0.1:5984\/_all_dbs<\/pre>\n
      Note that we added the “_all_dbs” string to the initial request.. The response should look like:<\/p>\n
      [\"_users\",\"blog\",\"test\"]<\/pre>\n
      It is showing our 2 databases named blog and test which were created earlier via the Futon UI.<\/p>\n
      Let\u2019s create another database, using the API this time:<\/p>\n
      curl -X PUT http:\/\/127.0.0.1:5984\/shopcart<\/pre>\n
      Executing this, the CouchDB will reply with:<\/p>\n
      {\"ok\":true}<\/pre>\n
      Retrieving the list of databases again shows some useful results:<\/p>\n
      curl -X GET http:\/\/127.0.0.1:5984\/_all_dbs<\/pre>\n
      The output shows:<\/p>\n
      [\"_users\",\"blog\",\"shopcart\",\"test\"]<\/pre>\n
      Let\u2019s create another database with the same database name:<\/p>\n
      curl -X PUT http:\/\/127.0.0.1:5984\/shopcart<\/pre>\n
      CouchDB will reply with:<\/p>\n
      {\"error\":\"file_exists\",\"reason\":\"The database could not be created, the file already exists.\"}<\/pre>\n
      We already have a database with that name, so CouchDB will respond with an error. Let\u2019s try again with a different database name:<\/p>\n
      curl -X PUT http:\/\/127.0.0.1:5984\/bookstore<\/pre>\n
      CouchDB will reply with:<\/p>\n
      {\"ok\":true}<\/pre>\n
      Retrieving the list of databases yet again shows some useful results:<\/p>\n
      curl -X GET http:\/\/127.0.0.1:5984\/_all_dbs<\/pre>\n
      CouchDB will respond with:<\/p>\n
      [\"bookstore\",\"_users\",\"blog\",\"shopcart\",\"test\"]<\/pre>\n
      To round things off, let\u2019s delete the second database:<\/p>\n
      curl -X DELETE http:\/\/127.0.0.1:5984\/bookstore<\/pre>\n
      CouchDB will reply with:<\/p>\n
      {\"ok\":true}<\/pre>\n
      The list of databases is now the same as it was before:<\/p>\n
      curl -X GET http:\/\/127.0.0.1:5984\/_all_dbs<\/pre>\n
      CouchDB will respond with:<\/p>\n
      [\"_users\",\"blog\",\"shopcart\",\"test\"]<\/pre>\n
      Everything is done using the standard HTTP methods, GET, PUT, POST, and DELETE with the appropriate URI.<\/p>\n
      <\/a>3.1 Documents<\/a><\/em><\/h3>\n
      Documents <\/em>are CouchDB\u2019s central data structure. To better understand and use CouchDB, we need to think in terms of documents<\/em>. In this chapter we will walk though the lifecycle of designing and saving a document. We\u2019ll follow up by reading documents and aggregating and querying them with views.<\/p>\n
      Documents are self-contained units of data. The data is usually made up of small native types such as integers and strings. Documents are the first level of abstraction over these native types. They provide some structure and logically group the primitive data. The height of a person might be encoded as an integer (176<\/i>), but this integer is usually part of a larger structure that contains a label (“height”: 176<\/i>) and related data ({“name”:”Chris”, “height”: 176}<\/i>).<\/p>\n
      How many data items can be put into the documents depends on the application and a bit on how we want to use views. Generally, a document corresponds to an object instance in the programming language.<\/p>\n
      Documents differ subtly from garden-variety objects in that they usually have authors and CRUD operations (create, read, update, delete). Document-based software (like the word processors and spreadsheets) build their storage model around saving documents so that authors get back what they created.<\/p>\n
      Validation functions are available so that we don\u2019t have to worry about bad data causing errors in our system. Often in document-based software, the client application edits and manipulates the data, saving it back.<\/p>\n
      Let’s suppose a user can comment on the item (\u201clovely book\u201d); we have the option to store the comments as an array, on the item document. This makes it trivial to find the item\u2019s comments, but, as they say, \u201cit doesn\u2019t scale.\u201d A popular item could have tens of comments, or even hundreds or more.<\/p>\n
      Instead of storing a list on the item document, in this case it may be acutally better to model comments into a collection of documents. There are patterns for accessing collections, which CouchDB makes easy. We likely want to show only 10 or 20 at a time and provide previous <\/em>and next <\/em>links. By handling comments as individual entities, we can group them with views. A group could be the entire collection or slices of 10 or 20, sorted by the item they apply to so that it\u2019s easy to grab the set we need.<\/p>\n
      Everything that will be handled separately in the application should be broken up into documents. Items are single, and comments are single, but we don\u2019t need to break them into smaller pieces. Views provide a convenient way to group our documents in meaningful ways.<\/p>\n
      <\/a>4. Common HTTP operations<\/h2>\n
      We start out by revisiting the basic operations we ran in the last chapter, looking behind the scenes. We will also discover what Futon runs in the background in order to give us the nice features we saw earlier.<\/p>\n
      While explaining the API bits and pieces, we sometimes need to take a larger detour to explain the reasoning for a particular request. This is a good opportunity for us to tell why CouchDB works the way it does.<\/p>\n
      The API can be subdivided into the following sections. We\u2019ll explore them individually:<\/p>\n
        \n
      1. Server<\/li>\n
      2. Databases<\/li>\n
      3. Documents<\/li>\n
      4. Replication<\/li>\n
      5. Server<\/li>\n<\/ol>\n
        This one is basic and simple. It can serve as a sanity check to see if CouchDB is running at all. It can also act as a safety guard for libraries that require a certain version of CouchDB. We\u2019re using the curl utility again:<\/p>\n
        curl http:\/\/127.0.0.1:5984\/<\/pre>\n
        CouchDB replies, all excited to get going:<\/p>\n
        {\"couchdb\":\"Welcome\",\"version\":\"1.0.1\"}<\/pre>\n
        We get back a JSON string, which, if parsed into a native object or data structure of our programming language, gives us access to the welcome string and version information.<\/p>\n
        This is not terribly useful, but it illustrates nicely the way CouchDB behaves. We send an HTTP request and we receive a JSON string in the HTTP response as a result.<\/p>\n
        <\/a>4.1 Databases<\/h3>\n
        Strictly speaking, CouchDB is a database management system (DMS). That means it can hold multiple databases. A database is a bucket that holds \u201crelated data.\u201d We\u2019ll explore later what that means in detail. In practice, the terminology is overlapping\u2014often people refer to a DMS as \u201ca database\u201d and also a database within the DMS as \u201ca database.\u201d We might follow that slight oddity, so don\u2019t get confused by it. In general, it should be clear from the context if we are talking about the whole of CouchDB or a single database within CouchDB.<\/p>\n
        Now let\u2019s make one! Note that we\u2019re now using the -X option again to tell curl to send a PUT request instead of the default GET request:<\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/student<\/pre>\n
        CouchDB replies:<\/p>\n
        {\"ok\":true}<\/pre>\n
        That\u2019s it. We created a database and CouchDB told us that all went well. What happens if we try to create a database that already exists? Let\u2019s try to create that database again:<\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/student<\/pre>\n
        CouchDB replies:<\/p>\n
        {\"error\":\"file_exists\",\"reason\":\"The database could not be created, the file already exists.\"}<\/pre>\n
        We get back an error. This is pretty convenient. CouchDB stores each database in a single file.<\/p>\n
        Let\u2019s create another database, this time with curl\u2019s -v (for \u201cverbose\u201d) option. The verbose option tells curl to show us not only the essentials\u2014the HTTP response body\u2014but all the underlying request and response details:<\/p>\n
        curl -vX PUT http:\/\/127.0.0.1:5984\/student-backup<\/pre>\n
        Curl elaborates:<\/p>\n
        * About to connect() to 127.0.0.1 port 5984 (#0)\r\n\r\n*   Trying 127.0.0.1... connected\r\n\r\n> PUT \/student-backup HTTP\/1.1\r\n\r\n> User-Agent: curl\/7.22.0 (x86_64-pc-linux-gnu) libcurl\/7.22.0 OpenSSL\/1.0.1 zlib\/1.2.3.4 libidn\/1.23 librtmp\/2.3\r\n\r\n> Host: 127.0.0.1:5984\r\n\r\n> Accept: *\/*\r\n\r\n>\r\n\r\n< HTTP\/1.1 201 Created\r\n\r\n< Server: CouchDB\/1.0.1 (Erlang OTP\/R14B)\r\n\r\n< Location: http:\/\/127.0.0.1:5984\/student-backup\r\n\r\n< Date: Sat, 15 Feb 2014 17:50:51 GMT\r\n\r\n< Content-Type: text\/plain;charset=utf-8\r\n\r\n< Content-Length: 12\r\n\r\n< Cache-Control: must-revalidate\r\n\r\n<  {\"ok\":true} * Connection #0 to host 127.0.0.1 left intact * Closing connection #0<\/pre>\n
        Let\u2019s step through this line by line in order to understand what\u2019s going on and find out what\u2019s important. Once we\u2019ve seen this output a few times, we\u2019ll be able to spot the important bits more easily.<\/p>\n
        * About to connect() to 127.0.0.1 port 5984 (#0)<\/pre>\n
        This is curl telling us that it is going to establish a TCP connection to the CouchDB server we specified in our request URI. Not at all important, except when debugging networking issues.<\/p>\n
        *   Trying 127.0.0.1... connected * Connected to 127.0.0.1 (127.0.0.1) port 5984 (#0)<\/pre>\n
        Curl tells us it successfully connected to CouchDB. Again, not important if there is no problem with the network. The following lines are prefixed with > and < characters. > means the line was sent to CouchDB verbatim (without the actual >). < means the line was sent back to curl by CouchDB.<\/p>\n
        > PUT \/student-backup HTTP\/1.1<\/pre>\n
        This initiates an HTTP request. Its method is PUT, the URI is \/student-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 We should be using HTTP\/1.1.<\/p>\n
        Next, we see a number of request headers. These are used to provide additional details about the request to CouchDB.<\/p>\n
        > User-Agent: curl\/7.22.0 (x86_64-pc-linux-gnu) libcurl\/7.22.0 OpenSSL\/1.0.1 zlib\/1.2.3.4 libidn\/1.23 librtmp\/2.3<\/pre>\n
        The User-Agent header tells CouchDB which piece of client software is doing the HTTP request. It\u2019s the curl program. 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 User-Agent header is not very relevant.<\/p>\n
        > Host: 127.0.0.1:5984<\/pre>\n
        The Host header is required by HTTP 1.1. It tells the server the hostname that came with the request.<\/p>\n
        > Accept: *\/*<\/pre>\n
        The Accept header tells CouchDB that curl accepts any media type. We\u2019ll look into why this is useful a little later.<\/p>\n
        ><\/pre>\n
        An empty line denotes that the request headers are now finished and the rest of the request contains data we\u2019re sending to the server. In this case, we\u2019re not sending any data, so the rest of the curl output is dedicated to the HTTP response.<\/p>\n
        < HTTP\/1.1 201 Created<\/pre>\n
        The first line of CouchDB\u2019s HTTP response includes the HTTP version information (again, to acknowledge that the requested version could be processed), an HTTP status code, and a status code message. Different requests trigger different response codes. There\u2019s a whole range of them telling the client (curl in our case) what effect the request had on the server. Or, if an error occurred, what kind of error.<\/p>\n
        RFC 2616 (the HTTP 1.1 specification) defines clear behavior for response codes. CouchDB fully follows the RFC. The 201 Created status code tells the client that the resource the request was made against was successfully created. No surprise here, but if we remember that we got an error message when we tried to create this database twice, we now know that this response could include a different response code.<\/p>\n
        Acting upon responses based on response codes is a common practice. For example, all response codes of 400 (or greater than that) inform us that some error occurred. If we want to shortcut the logic and immediately deal with the error, we could just check a >= 400 response code.<\/p>\n
        < Server: CouchDB\/0.10.1 (Erlang OTP\/R13B)<\/pre>\n
        The Server header is good for diagnostics. It tells us which CouchDB version and which underlying Erlang version we are talking to. In general, we can ignore this header, but it is good to know it\u2019s there if We need it.<\/p>\n
        < Date: Sun, 05 Jul 2009 22:48:28 GMT<\/pre>\n
        The Date header tells the time of the server. Since client and server time are not necessarily synchronized, this header is purely informational. We shouldn\u2019t build any critical application logic on top of this!<\/p>\n
        < Content-Type: text\/plain;charset=utf-8<\/pre>\n
        The Content-Type header tells which MIME type the HTTP response body uses and what encoding is used for it. We already know that CouchDB returns JSON strings. The appropriate Content-Type header is application\/json. Why do we see text\/plain? This is where pragmatism wins over purity. Sending an application\/json Content-Type header will make a browser offer 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 text\/plain content type, so all browsers will display the JSON as text.<\/p>\n
        There are some extensions that make our browser JSON-aware, but they are not installed by default. For more information, look at the popular JSONView extension, available for both Firefox and Chrome.<\/p>\n
        If we send Accept: application\/json in our request, CouchDB knows that we can deal with a pure JSON response with the proper Content-Type header and will use it instead of text\/plain.<\/p>\n
        < Content-Length: 12<\/pre>\n
        The Content-Length header simply tells us how many bytes the response body has.<\/p>\n
        < Cache-Control: must-revalidate<\/pre>\n
        This Cache-Control header tells us, or any proxy server between CouchDB and us, not to cache this response.<\/p>\n
        <<\/pre>\n
        This empty line tells us we\u2019re done with the response headers and what follows now is the response body.<\/p>\n
        * Connection #0 to host 127.0.0.1 left intact * Closing connection #0<\/pre>\n
        The last two lines are curl telling us that it kept the TCP connection it opened in the beginning open for a moment, but then closed it after it received the entire response.<\/p>\n
        > curl -vX DELETE http:\/\/127.0.0.1:5984\/albums-backup<\/pre>\n
        This deletes a CouchDB database. The request will remove the file that the database contents are stored in. We need to use this command with care, as our data will be deleted without a chance to bring it back easily if we don\u2019t have a backup copy.<\/p>\n
        The console will look like this:<\/p>\n
        * About to connect() to 127.0.0.1 port 5984 (#0)\r\n\r\n*   Trying 127.0.0.1... connected\r\n\r\n> DELETE \/student-backup HTTP\/1.1\r\n\r\n> User-Agent: curl\/7.22.0 (x86_64-pc-linux-gnu) libcurl\/7.22.0 OpenSSL\/1.0.1 zlib\/1.2.3.4 libidn\/1.23 librtmp\/2.3\r\n\r\n> Host: 127.0.0.1:5984\r\n\r\n> Accept: *\/*\r\n\r\n>\r\n\r\n< HTTP\/1.1 200 OK\r\n\r\n< Server: CouchDB\/1.0.1 (Erlang OTP\/R14B)\r\n\r\n< Date: Sat, 15 Feb 2014 17:53:58 GMT\r\n\r\n< Content-Type: text\/plain;charset=utf-8\r\n\r\n< Content-Length: 12\r\n\r\n< Cache-Control: must-revalidate\r\n\r\n<\r\n\r\n{\"ok\":true}\r\n\r\n* Connection #0 to host 127.0.0.1 left intact\r\n\r\n* Closing connection #0\r\n<\/pre>\n
        This section went knee-deep into HTTP and set the stage for discussing the rest of the core CouchDB API. Next stop: documents.<\/p>\n
        <\/a>4.2 Documents<\/h3>\n
        Let\u2019s have a closer look at our document creation requests with the curl -v flag that was helpful when we explored the database API earlier. This is also a good opportunity to create more documents that we can use in later examples.<\/p>\n
        We\u2019ll add some more of our favorite music albums. Get a fresh UUID from the \/_uuids resource. If we don\u2019t remember how that works, w can look it up a few pages back.<\/p>\n
        curl -vX PUT http:\/\/127.0.0.1:5984\/albums\/70b50bfa0a4b3aed1f8aff9e92dc16a0 -d '{\"title\":\"Blackened Sky\",\"artist\":\"Biffy Clyro\",\"year\":2002}'<\/pre>\n
        Now with the -v option, CouchDB\u2019s reply (with only the important bits shown) looks like this:<\/p>\n
        > PUT \/albums\/70b50bfa0a4b3aed1f8aff9e92dc16a0 HTTP\/1.1\r\n>\r\n< HTTP\/1.1 201 Created\r\n< Location: http:\/\/127.0.0.1:5984\/albums\/70b50bfa0a4b3aed1f8aff9e92dc16a0\r\n< Etag: \"1-2248288203\"\r\n<\r\n{\"ok\":true,\"id\":\"70b50bfa0a4b3aed1f8aff9e92dc16a0\",\"rev\":\"1-2248288203\"}\r\n<\/pre>\n
        We\u2019re getting back the 201 Created HTTP status code in the response headers, as we saw earlier when we created a database. The Location header gives us a full URL to our newly created document and there\u2019s a new header. An Etag in HTTP-speak identifies a specific version of a resource. In this case, it identifies a specific version (the first one) of our new document. An Etag is the same as a CouchDB document revision number, and it shouldn\u2019t come as a surprise that CouchDB uses revision numbers for Etags. Etags are useful for caching infrastructures.<\/p>\n
        <\/a>4.3 Attachments<\/h3>\n
        CouchDB documents can have attachments just like an email message can have attachments. An attachment is identified by a name and includes its MIME type (or Content-Type) and the number of bytes the attachment contains. Attachments can consist of any type of data. It is easier to think about attachments as files attached to a document. These files can be text, images, Word documents, music, or movie files. Let\u2019s make one.<\/p>\n
        Attachments get their own URL where we can upload data. Let’s suppose we want to add the album artwork to the 6e1295ed6c29495e54cc05947f18c8af document (\u201cThere is Nothing Left to Lose\u201d), and let\u2019s also say the artwork is in a file artwork.jpg in the current directory:<\/p>\n
        > curl -vX PUT http:\/\/127.0.0.1:5984\/albums\/6e1295ed6c29495e54cc05947f18c8af\/artwork.jpg?rev=2-2739352689 --data-binary @artwork.jpg -H \"Content-Type: image\/jpg\"<\/pre>\n
        The –data-binary @ option tells curl to read a file\u2019s contents into the HTTP request body. We\u2019re using the -H option to tell CouchDB that we\u2019re 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 the data for download. This will come in handy later. Note that we need to provide the current revision number of the document we\u2019re attaching the artwork to, just as if we would update the document.<\/p>\n
        If we request the document again, we will see a new member:<\/p>\n
        curl http:\/\/127.0.0.1:5984\/albums\/6e1295ed6c29495e54cc05947f18c8af<\/pre>\n
        CouchDB replies:<\/p>\n
        {\"_id\":\"6e1295ed6c29495e54cc05947f18c8af\",\"_rev\":\"3-131533518\",\"title\": \"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\",\"year\":\"1997\",\"_attachments\":{\"artwork.jpg\":{\"stub\":true,\"content_type\":\"image\/jpg\",\"length\":52450}}}<\/pre>\n
        _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 requesting this document, we\u2019d get a Base64-encoded string containing the attachment data.<\/p>\n
        We\u2019ll have a look at more document request options later as we explore more features of CouchDB, such as replication, which is the next topic.<\/p>\n
        <\/a>4.4 Replication<\/h3>\n
        CouchDB replication is a mechanism to synchronize databases. Much like rsync synchronizes two directories locally or over a network, replication synchronizes two databases locally or remotely.<\/p>\n
        Using a simple POST request, we tell CouchDB the source and the target of a replication and CouchDB will figure out which documents and new document revisions exist on the source DB and they are not yet on the target DB, and will proceed to move the missing documents and revisions over.<\/p>\n
        First, we\u2019ll create a target database. Note that CouchDB won\u2019t automatically create a target database and will return a replication failure if the target doesn\u2019t exist:<\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/albums-replica<\/pre>\n
        Now we can use the database albums-replica as a replication target:<\/p>\n
        curl -vX POST http:\/\/127.0.0.1:5984\/_replicate -d '{\"source\":\"albums\",\"target\":\"albums-replica\"}' -H \"Content-Type: application\/json\"<\/pre>\n
        CouchDB replies (this time we formatted the output so We can read it more easily):<\/p>\n
        {\r\n  \"history\": [\r\n    {\r\n      \"start_last_seq\": 0,\r\n      \"missing_found\": 2,\r\n      \"docs_read\": 2,\r\n      \"end_last_seq\": 5,\r\n      \"missing_checked\": 2,\r\n      \"docs_written\": 2,\r\n      \"doc_write_failures\": 0,\r\n      \"end_time\": \"Sat, 11 Jul 2009 17:36:21 GMT\",\r\n      \"start_time\": \"Sat, 11 Jul 2009 17:36:20 GMT\"\r\n    }\r\n  ],\r\n  \"source_last_seq\": 5,\r\n  \"session_id\": \"924e75e914392343de89c99d29d06671\",\r\n  \"ok\": true\r\n}<\/pre>\n
        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 replication closes. If we have a lot of documents, it\u2019ll take a while until they are all replicated and we won\u2019t get back the replication response until all documents are replicated. It is important to note that 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.<\/p>\n
        We\u2019ll punt on the details again: the “ok”: true at the end tells us all went well. If we have a look at the albums-replica database, we should see all the documents that we created in the albums database.<\/p>\n
        In CouchDB terms, we created a local copy of a database. This is useful for backups or to keep snapshots of a specific state of data around for later.<\/p>\n
        There are more types of replication useful in other situations. The source and target members of our replication request are actually links (like in HTML) and so far we\u2019ve seen links relative to the server we\u2019re working on (hence local). We can also specify a remote database as the target:<\/p>\n
        curl -vX POST http:\/\/127.0.0.1:5984\/_replicate -d '{\"source\":\"albums\",\"target\":\"http:\/\/example.org:5984\/albums-replica\"}' -H \"Content-Type: application\/json\"<\/pre>\n
        Using a local source and a remote target database is called push replication. We\u2019re pushing changes to a remote server.<\/p>\n
        We can also use a remote source and a local target to do a pull replication. This is great for getting the latest changes from a server that is used by others:<\/p>\n
        curl -vX POST http:\/\/127.0.0.1:5984\/_replicate -d '{\"source\":\"http:\/\/example.org:5984\/albums-replica\",\"target\":\"albums\"}' -H \"Content-Type: application\/json\"<\/pre>\n
        Finally, we can run remote replication, which is mostly useful for management operations:<\/p>\n
        curl -vX POST http:\/\/127.0.0.1:5984\/_replicate -d '{\"source\":\"http:\/\/example.org:5984\/albums\",\"target\":\"http:\/\/example.org:5984\/albums-replica\"}' -H \"Content-Type: application\/json\"<\/pre>\n
        <\/a>5. JSON<\/h2>\n
        CouchDB uses JavaScript Object Notation (JSON) for data storage. JSON is a lightweight format based on a subset of JavaScript syntax. One of the best bits about JSON is that it\u2019s easy to read and write by hand, much more so than something like XML. We can parse it naturally with JavaScript because it shares part of the same syntax. This really comes in handy when we\u2019re building dynamic web applications and we want to fetch some data from the server.<\/p>\n
        Here\u2019s a sample JSON document:<\/p>\n
        {\r\n    \"Subject\": \"I like Plankton\",\r\n    \"Author\": \"Rusty\",\r\n    \"PostedDate\": \"2006-08-15T17:30:12-04:00\",\r\n    \"Tags\": [\r\n        \"plankton\",\r\n        \"baseball\",\r\n        \"decisions\"\r\n    ],\r\n    \"Body\": \"I decided today that I don't like baseball. I like plankton.\"\r\n}<\/pre>\n
        We can see that the general structure is based around key\/value pairs and lists of things.<\/p>\n
        <\/a>5.1 Data Types<\/h3>\n
        JSON has a number of basic data types We can use. We\u2019ll cover them all here.<\/p>\n
        <\/a>5.2 Numbers<\/h3>\n
        We can have positive integers: “Count”: 253<\/p>\n
        Or negative integers: “Score”: -19<\/p>\n
        Or floating-point numbers: “Area”: 456.31<\/p>\n
        Or scientific notation: “Density”: 5.6e+24<\/p>\n
        <\/a>5.3 Strings<\/h3>\n
        We can use strings for values:<\/p>\n
        \"Author\": \"Rusty\"<\/pre>\n
        We have to escape some special characters, like tabs or newlines:<\/p>\n
        \"poem\": \"May I compare thee to some\\\\n\\\\tsalty plankton.\"<\/pre>\n
        The JSON site<\/a> has details on what needs to be escaped.<\/p>\n
        <\/a>5.4 Booleans<\/h3>\n
        We can have boolean true values:<\/p>\n
        \"Draft\": true<\/pre>\n
        Or boolean false values:<\/p>\n
        \"Draft\": false<\/pre>\n
        Arrays<\/strong><\/p>\n
        An array is a list of values:<\/p>\n
        \"Tags\": [\"plankton\", \"baseball\", \"decisions\"]<\/pre>\n
        An array can contain any other data type, including arrays:<\/p>\n
        \"Context\": [\"dog\", [1, true], {\"Location\": \"puddle\"}]<\/pre>\n
        Objects<\/strong><\/p>\n
        An object is a list of key\/value pairs:<\/p>\n
        {\"Subject\": \"I like Plankton\", \"Author\": \"Rusty\"}<\/pre>\n
        Nulls<\/strong><\/p>\n
        We can have null values:<\/p>\n
        \"Surname\": null<\/pre>\n
        <\/a>6. Documents<\/h2>\n
        Documents are CouchDB\u2019s central data structure. The idea behind a document is, unsurprisingly, that of a real-world document \u2013 a sheet of paper such as an invoice, a recipe, or a business card. We have already learned that CouchDB uses the JSON format to store documents. Let\u2019s see how this storing works at the lowest level.<\/p>\n
        Each document in CouchDB has an ID. This ID is unique per database. We are free to choose any string to be the ID, but for best results we recommend a UUID (or GUID), i.e., a Universally (or Globally) Unique IDentifier. UUIDs are random numbers that have such a low collision probability. We can make thousands of UUIDs per minute for millions of years without ever creating a duplicate. This is a great way to ensure two independent people cannot create two different documents with the same ID. Why should we care what somebody else is doing? For one, somebody else could be at a later time or on a different computer; secondly, CouchDB replication let’s us share documents with others and using UUIDs ensures that it all works. But more on that later; let\u2019s make some documents:<\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/shopcart\/6e1295ed6c29495e54cc05947f18c8af -d '{\"title\":\"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\"}'<\/pre>\n
        CouchDB replies:<\/p>\n
        {\"ok\":true,\"id\":\"6e1295ed6c29495e54cc05947f18c8af\",\"rev\":\"1-2902191555\"}<\/pre>\n
        The curl command appears complex, but let\u2019s break it down. First, -X PUT tells curl to make a PUT request. It is followed by the URL that specifies Wer 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 Wer document\u2019s ID. Finally, the -d flag tells curl to use the following string as the body for the PUT request. The string is a simple JSON structure including title and artist attributes with their respective values.<\/p>\n
        A CouchDB document is simply a JSON object. We can use any JSON structure with nesting. We can fetch the document’s revision information by adding ?revs_info=true to the get request.<\/p>\n
        To get a UUID, we use:<\/p>\n
        curl -X GET http:\/\/127.0.0.1:5984\/_uuids<\/pre>\n
        CouchDb will reply us back, like this:<\/p>\n
        {\"uuids\":[\"6e1295ed6c29495e54cc05947f18c8af\"]}<\/pre>\n
        Here are two simple examples of documents:<\/p>\n
        {\r\n \"_id\":\"discussion_tables\",\r\n \"_rev\":\"D1C946B7\",\r\n \"Sunrise\":true,\r\n \"Sunset\":false,\r\n \"FullHours\":[1,2,3,4,5,6,7,8,9,10],\r\n \"Activities\": [\r\n   {\"Name\":\"Football\", \"Duration\":2, \"DurationUnit\":\"Hours\"},\r\n   {\"Name\":\"Breakfast\", \"Duration\":40, \"DurationUnit\":\"Minutes\", \"Attendees\":[\"Jan\", \"Damien\", \"Laura\", \"Gwendolyn\", \"Roseanna\"]}\r\n ]\r\n}<\/pre>\n
        {\r\n \"_id\":\"some_doc_id\",\r\n \"_rev\":\"D1C946B7\",\r\n \"Subject\":\"I like Plankton\",\r\n \"Author\":\"Rusty\",\r\n \"PostedDate\":\"2006-08-15T17:30:12-04:00\",\r\n \"Tags\":[\"plankton\", \"baseball\", \"decisions\"],\r\n \"Body\":\"I decided today that I don't like baseball. I like plankton.\"\r\n}<\/pre>\n
        <\/a>6.1 Special Fields<\/h3>\n
        Note that any top-level fields within a JSON document containing a name that starts with a _ prefix are reserved for use by CouchDB itself. Also see Reserved_words. Currently (0.10+) reserved fields are:<\/p>\n
        \n\n\n\n\n\n\n\n\n\n\n\n\n
        Field Name<\/strong><\/td>\nDescription<\/strong><\/em><\/td>\n<\/tr>\n
         <\/em>_id<\/em><\/td>\nThe unique identifier of the document (mandatory <\/strong>and immutable<\/strong>)<\/em><\/td>\n<\/tr>\n
        _rev<\/em><\/td>\nThe current MVCC-token\/revision of this document (mandatory <\/strong>and immutable<\/strong>)<\/em><\/td>\n<\/tr>\n
        _attachments<\/em><\/td>\nIf the document has attachments, _attachments holds a (meta-)data structure (see section on HTTP_Document_API#Attachments<\/a>)<\/em><\/td>\n<\/tr>\n
        _deleted<\/em><\/td>\nIndicates that this document has been deleted and previous revisions will be removed on next compaction run<\/em><\/td>\n<\/tr>\n
        _revisions<\/em><\/td>\nRevision history of the document<\/em><\/td>\n<\/tr>\n
        _revs_info<\/em><\/td>\nA list of revisions of the document, and their availability<\/em><\/td>\n<\/tr>\n
        _conflicts<\/em><\/td>\nInformation about conflicts<\/em><\/td>\n<\/tr>\n
        _deleted_conflicts<\/em><\/td>\nInformation about conflicts<\/em><\/td>\n<\/tr>\n
        _local_seq<\/em><\/td>\nSequence number of the revision in the database (as found in the _changes feed)<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        Table 1<\/p>\n<\/div>\n
        To request a special field to be returned along with the normal fields we get when we request a document, add the desired field as a query parameter without the leading underscore in a GET request:<\/p>\n
        curl -X GET 'http:\/\/localhost:5984\/my_database\/my_document?conflicts=true'<\/pre>\n
        This request will return a document that includes the special field ‘_conflicts’ which contains all the conflicting revisions of “my_document”.<\/p>\n
        [Exception:<\/strong> The query parameter for the _revisions<\/em> special field is ‘revs’, not ‘revisions’.]<\/p>\n
        <\/a>6.2 Document IDs<\/h3>\n
        Document IDs don’t have restrictions on what characters can be used. Although it should work, it is recommended to use non-special characters for document IDs. By using special characters, we have to be aware of proper URL en-\/decoding. Documents prefixed with _<\/em> are special documents:<\/strong><\/p>\n
        \n\n\n\n\n\n
        Document ID prefix<\/strong><\/td>\nDescription<\/strong><\/em><\/td>\n<\/tr>\n
        _design\/<\/em><\/td>\nare DesignDocuments<\/a><\/em><\/td>\n<\/tr>\n
        _local\/<\/em><\/strong><\/td>\nare not being replicated (local documents) and used for Replication<\/a> checkpointing.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
        Table 2<\/p>\n<\/div>\n
        We can have \/ as part of the document ID but if We refer to a document in a URL We must always encode it as %2F. One special case is _design\/ documents, those accept either \/ or %2F for the \/ after _design<\/em>, although \/ is preferred and %2F is still needed for the rest of the DocID.<\/p>\n
        <\/a>6.3 Working With Documents Over HTTP<\/h3>\n
        GET<\/strong><\/p>\n
        To retrieve a document, simply perform a GET<\/em> operation at the document’s URL:<\/p>\n
        curl -X GET http:\/\/127.0.0.1:5984\/shopcart\/6e1295ed6c29495e54cc05947f18c8af<\/pre>\n
        Here is the server’s response:<\/p>\n
        {\"_id\":\"6e1295ed6c29495e54cc05947f18c8af\",\"_rev\":\"1-4b39c2971c9ad54cb37e08fa02fec636\",\"title\":\"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\"}<\/pre>\n
        <\/a>7. Revisions<\/h2>\n
        If we want to change a document in CouchDB, we don\u2019t tell it to go and find a field in a specific document and insert a new value. Instead, we load the full document out of CouchDB, make our changes in the JSON structure (or object, when we 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 <\/i>value.<\/p>\n
        If we want to update or delete a document, CouchDB expects us to include the_rev <\/i>field of the revision we wish to change. When CouchDB accepts the change, it will generate a new revision number. This mechanism ensures that, in case somebody else made a change without us knowing before we got to request the document update, CouchDB will not accept our update because we are likely to overwrite data we didn\u2019t know that even existed. Or simplified: whoever saves a change to a document first, wins. Let\u2019s see what happens if we don\u2019t provide a _rev <\/i>field (which is equivalent to providing a outdated value):<\/b><\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/shopcart\/6e1295ed6c29495e54cc05947f18c8af -d '{\"title\":\"There is Nothing Left to Lose\",\"artist\":\"Foo Fighters\",\"year\":\"1997\"}'<\/pre>\n
        CouchDB replies:<\/p>\n
        {\"error\":\"conflict\",\"reason\":\"Document update conflict.\"}<\/pre>\n
        If we see this, add the latest revision number of your document to the JSON structure:<\/b><\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/shopcart\/6e1295ed6c29495e54cc05947f18c8af -d '{\"_rev\":\"1-2902191555\",\"title\":\"There is Nothing Left to Lose\", \"artist\":\"Foo Fighters\",\"year\":\"1997\"}'<\/pre>\n
        Now we see why it was handy that CouchDB returned that _rev<\/i> when we made the initial request. CouchDB replies:<\/p>\n
        {\"ok\":true,\"id\":\"6e1295ed6c29495e54cc05947f18c8af\",\"rev\":\"2-2739352689\"}<\/pre>\n
        <\/a>7.1 Accessing Previous Revisions<\/h3>\n
        The above example gets the current revision. We may be able to get a specific revision by using the following syntax:<\/p>\n
        GET \/somedatabase\/some_doc_id?rev=946B7D1C HTTP\/1.0<\/pre>\n
        To find out what revisions are available for a document, we can do:<\/p>\n
        GET \/somedatabase\/some_doc_id?revs_info=true HTTP\/1.0<\/pre>\n
        This returns the current revision of the document, but with an additional _revs_info<\/em> field, whose value is an array of objects, one per revision. For example:<\/p>\n
        {\r\n  \"_revs_info\": [\r\n    {\"rev\": \"3-ffffff\", \"status\": \"available\"},\r\n    {\"rev\": \"2-eeeeee\", \"status\": \"missing\"},\r\n    {\"rev\": \"1-dddddd\", \"status\": \"deleted\"},\r\n  ]\r\n}<\/pre>\n
        Here, available <\/em>means the revision content is stored in the database and can still be retrieved. The other values indicate that the content of that revision is not available.<\/p>\n
        Alternatively, the _revisions field, used by the replicator, can return an array of revision IDs more efficiently. The numeric prefixes are removed, with a “start” value indicating the prefix for the first (most recent) ID:<\/p>\n
        {\r\n  \"_revisions\": {\r\n    \"start\": 3,\r\n    \"ids\": [\"fffff\", \"eeeee\", \"ddddd\"]\r\n  }\r\n}<\/pre>\n
        We can fetch the bodies of multiple revisions at once using the parameter open_revs=[“rev1″,”rev2”,…], or We can fetch all leaf revisions using open_revs=all. The JSON returns an array of objects with an “ok” key pointing to the document, or a “missing” key pointing to the rev string.<\/p>\n
        [\r\n{\"missing\":\"1-fbd8a6da4d669ae4b909fcdb42bb2bfd\"},\r\n{\"ok\":{\"_id\":\"test\",\"_rev\":\"2-5bc3c6319edf62d4c624277fdd0ae191\",\"hello\":\"foo\"}}\r\n]<\/pre>\n
        <\/a>7.2 HEAD<\/h3>\n
        A HEAD request returns basic information about the document, including its current revision.<\/p>\n
        HEAD \/somedatabase\/some_doc_id HTTP\/1.0\r\nHTTP\/1.1 200 OK\r\nEtag: \"946B7D1C\"\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nContent-Length: 256<\/pre>\n
        <\/a>7.3 PUT<\/h3>\n
        To create new document we can either use a POST <\/em>operation or a PUT <\/em>operation. To create\/update a named document using the PUT operation, the URL must point to the document’s location.<\/p>\n
        The following is an example HTTP PUT<\/em>. It will cause the CouchDB server to generate a new revision ID and save the document with it.<\/p>\n
        PUT \/somedatabase\/some_doc_id HTTP\/1.0\r\nContent-Length: 245\r\nContent-Type: application\/json\r\n\r\n{\r\n  \"Subject\":\"I like Plankton\",\r\n  \"Author\":\"Rusty\",\r\n  \"PostedDate\":\"2006-08-15T17:30:12-04:00\",\r\n  \"Tags\":[\"plankton\", \"baseball\", \"decisions\"],\r\n  \"Body\":\"I decided today that I don't like baseball. I like plankton.\"\r\n}<\/pre>\n
        Here is the server’s response.<\/p>\n
        HTTP\/1.1 201 Created\r\nEtag: \"946B7D1C\"\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\"ok\": true, \"id\": \"some_doc_id\", \"rev\": \"946B7D1C\"}\r\n<\/pre>\n
        To update an existing document, we also issue a PUT<\/em>request. In this case, the JSON body must contain a _rev <\/em>property, which lets CouchDB know which revision the edits are based on. If the revision of the document currently stored in the database doesn’t match, then a 409 <\/em>conflict error is returned.<\/p>\n
        If the revision number does match what’s in the database, a new revision number is generated and returned to the client.<\/p>\n
        For example:<\/p>\n
        PUT \/somedatabase\/some_doc_id HTTP\/1.0\r\nContent-Length: 245\r\nContent-Type: application\/json\r\n\r\n{\r\n  \"_id\":\"some_doc_id\",\r\n  \"_rev\":\"946B7D1C\",\r\n  \"Subject\":\"I like Plankton\",\r\n  \"Author\":\"Rusty\",\r\n  \"PostedDate\":\"2006-08-15T17:30:12-04:00\",\r\n  \"Tags\":[\"plankton\", \"baseball\", \"decisions\"],\r\n  \"Body\":\"I decided today that I don't like baseball. I like plankton.\"\r\n}<\/pre>\n
        Here is the server’s response if what is stored in the database is a revision 946B7D1C<\/em> of document some_doc_id<\/em>.<\/p>\n
        HTTP\/1.1 201 Created\r\nEtag: \"2774761002\"\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\"ok\":true, \"id\":\"some_doc_id\", \"rev\":\"2774761002\"}<\/pre>\n
        And here is the server’s response if there is an update conflict (what is currently stored in the database is not revision 946B7D1C <\/em>of document some_doc_id<\/em>).<\/p>\n
        HTTP\/1.1 409 Conflict\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Length: 33\r\nConnection: close\r\n\r\n{\"error\":\"conflict\",\"reason\":\"Document update conflict.\"}<\/pre>\n
        There is a query option batch=ok<\/em>which can be used to achieve higher throughput at the cost of lower guarantees. When a PUT<\/em>(or a document POST<\/em>as described below) is sent using this option, it is not immediately written to disk. Instead it is stored in memory on a per-user basis for a second or so (or the number of docs in memory reaches a certain point). After the threshold has passed, the docs are committed to disk. Instead of waiting for the doc to be written to disk before responding, CouchDB sends an HTTP 202 Accepted <\/em>response immediately.<\/em><\/p>\n
        batch=ok <\/em>is not suitable for crucial data, but it ideal for applications like logging which can accept the risk that a small proportion of updates could be lost due to a crash. Docs in the batch can also be flushed manually using the _ensure_full_commit <\/em>API.<\/p>\n
        <\/a>7.4 POST<\/h3>\n
        The POST<\/em>operation can be used to create a new document with a server generated DocID. To do so, the URL must point to the database’s location. To create a named document, use the PUT<\/em>method instead.<\/p>\n
        It is recommended that we avoid POST<\/em>when possible, because proxies and other network intermediaries will occasionally resend POST<\/em>requests, which can result in duplicate document creation. If our client software is not capable of guaranteeing uniqueness of generated UUIDs, use a GET<\/em>to \/_uuids?count=100<\/em>to retrieve a list of document IDs for future PUT<\/em> requests. Please note that the \/_uuids<\/em>-call does not check for existing document ids; collision-detection happens when We are trying to save a document.<\/p>\n
        The following is an example HTTP POST<\/em>. It will cause the CouchDB server to generate a new DocID and revision ID and save the document with it.<\/p>\n
        POST \/somedatabase\/ HTTP\/1.0\r\nContent-Length: 245\r\nContent-Type: application\/json\r\n\r\n{\r\n  \"Subject\":\"I like Plankton\",\r\n  \"Author\":\"Rusty\",\r\n  \"PostedDate\":\"2006-08-15T17:30:12-04:00\",\r\n  \"Tags\":[\"plankton\", \"baseball\", \"decisions\"],\r\n  \"Body\":\"I decided today that I don't like baseball. I like plankton.\"\r\n}\r\n<\/pre>\n
        Here is the server’s response:<\/p>\n
        HTTP\/1.1 201 Created\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\"ok\":true, \"id\":\"123BAC\", \"rev\":\"946B7D1C\"}<\/pre>\n
        As of 0.11 CouchDB supports handling of multipart\/form-data encoded updates. This is used by Futon and not considered a public API. All such requests must contain a valid Referer header.<\/p>\n
        <\/a>7.5 DELETE<\/h3>\n
        To delete a document, perform a DELETE<\/em> operation at the document’s location, passing the rev<\/em> parameter with the document’s current revision. If successful, it will return the revision id for the deletion stub.<\/p>\n
        DELETE \/somedatabase\/some_doc?rev=1582603387 HTTP\/1.0<\/pre>\n
        As an alternative we can submit the rev<\/em> parameter with the etag header field If-Match<\/em>.<\/p>\n
        DELETE \/somedatabase\/some_doc HTTP\/1.0\r\nIf-Match: \"1582603387\"<\/pre>\n
        And the response:<\/p>\n
        HTTP\/1.1 200 OK\r\nEtag: \"2839830636\"\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\"ok\":true,\"rev\":\"2839830636\"}<\/pre>\n
        Note: Deleted documents remain in the database forever, even after compaction, to allow eventual consistency when replicating. If we delete using the DELETE method above, only the _id, _rev and a deleted flag are preserved. If we deleted a document by adding “_deleted”:true then all the fields of the document are preserved. This is to allow, for example, to record the time we deleted a document, or the reason we deleted it.<\/p>\n
        <\/a>7.6 COPY<\/h3>\n
        Note that this is a non-standard extension to HTTP.<\/p>\n
        We can copy documents by sending an HTTP COPY request. This allows us to duplicate the contents (and attachments) of a document to a new document under a different document id without first retrieving it from CouchDB. Use the Destination<\/em> header to specify the document that We want to copy to (the target document).<\/p>\n
        It is not possible to copy documents between databases and it is not (yet) possible to perform bulk copy operations.<\/p>\n
        COPY \/somedatabase\/some_doc HTTP\/1.1\r\nDestination: some_other_doc\r\n<\/pre>\n
        If we want to overwrite an existing document, we need to specify the target document’s revision with a rev<\/em> parameter in the Destination<\/em> header:<\/p>\n
        COPY \/somedatabase\/some_doc HTTP\/1.1\r\nDestination: some_other_doc?rev=rev_id<\/pre>\n
        The response in both cases includes the target document’s revision:<\/p>\n
        HTTP\/1.1 201 Created\r\nServer: CouchDB\/0.9.0a730122-incubating (Erlang OTP\/R12B)\r\nEtag: \"355068078\"\r\nDate: Mon, 05 Jan 2009 11:12:49 GMT\r\nContent-Type: text\/plain;charset=utf-8\r\nContent-Length: 41\r\nCache-Control: must-revalidate\r\n\r\n{\"ok\":true,\"id\":\"some_other_doc\",\"rev\":\"355068078\"}<\/pre>\n
        <\/a>7.7 All Documents<\/h3>\n
        7.6.1 all_docs<\/h4>\n
        To get a listing of all documents in a database, use the special _all_docs<\/em> URI. This is a specialized View so the Querying Options of the HTTP_view_API<\/a> apply here.<\/p>\n
        GET \/somedatabase\/_all_docs HTTP\/1.0<\/pre>\n
        This will return a listing of all documents and their revision IDs, ordered by DocID (case sensitive):<\/p>\n
        HTTP\/1.1 200 OK\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\r\n  \"total_rows\": 3, \"offset\": 0, \"rows\": [\r\n    {\"id\": \"doc1\", \"key\": \"doc1\", \"value\": {\"rev\": \"4324BB\"}},\r\n    {\"id\": \"doc2\", \"key\": \"doc2\", \"value\": {\"rev\":\"2441HF\"}},\r\n    {\"id\": \"doc3\", \"key\": \"doc3\", \"value\": {\"rev\":\"74EC24\"}}\r\n  ]\r\n}<\/pre>\n
        Use the query argument descending=true<\/em> to reverse the order of the output table:<\/p>\n
        Will return the same as before but in reverse order:<\/p>\n
        HTTP\/1.1 200 OK\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\r\n  \"total_rows\": 3, \"offset\": 0, \"rows\": [\r\n    {\"id\": \"doc3\", \"key\": \"doc3\", \"value\": {\"rev\":\"74EC24\"}},\r\n    {\"id\": \"doc2\", \"key\": \"doc2\", \"value\": {\"rev\":\"2441HF\"}},\r\n    {\"id\": \"doc1\", \"key\": \"doc1\", \"value\": {\"rev\": \"4324BB\"}}\r\n  ]\r\n}\r\n<\/pre>\n
        The query string parameters startkey<\/em>, endkey<\/em> and limit<\/em> may also be used to limit the result set. For example:<\/p>\n
        GET \/somedatabase\/_all_docs?startkey=\"doc2\"&amp;limit=2 HTTP\/1.0<\/pre>\n
        Will return:<\/p>\n
        HTTP\/1.1 200 OK\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\r\n  \"total_rows\": 3, \"offset\": 1, \"rows\": [\r\n    {\"id\": \"doc2\", \"key\": \"doc2\", \"value\": {\"rev\":\"2441HF\"}},\r\n    {\"id\": \"doc3\", \"key\": \"doc3\", \"value\": {\"rev\":\"74EC24\"}}\r\n  ]\r\n}\r\n<\/pre>\n
        Use endkey<\/em> if you are interested in a specific range of documents:<\/p>\n
        GET \/somedatabase\/_all_docs?startkey=\"doc2\"&amp;endkey=\"doc3\" HTTP\/1.0<\/pre>\n
        This will get keys inbetween and including doc2 and doc3; e.g. doc2-b<\/em> and doc234<\/em>.<\/p>\n
        Both approaches can be combined with descending<\/em>:<\/p>\n
        GET \/somedatabase\/_all_docs?startkey=\"doc2\"&amp;limit=2&amp;descending=true HTTP\/1.0<\/pre>\n
        Will return:<\/p>\n
        HTTP\/1.1 200 OK\r\nDate: Thu, 17 Aug 2006 05:39:28 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\r\n  \"total_rows\": 3, \"offset\": 1, \"rows\": [\r\n    {\"id\": \"doc3\", \"key\": \"doc3\", \"value\": {\"rev\":\"74EC24\"}},\r\n    {\"id\": \"doc2\", \"key\": \"doc2\", \"value\": {\"rev\":\"2441HF\"}}\r\n  ]\r\n}<\/pre>\n
        If we add include_docs=true<\/em> to a request to _all_docs<\/em> not only metadata but also the documents themselves are returned.<\/p>\n
        7.6.2 _changes<\/h4>\n
        This allows us to see all the documents that were updated and deleted, in the order these actions are done:<\/p>\n
        GET \/somedatabase\/_changes HTTP\/1.0<\/pre>\n
        Will return something of the form:<\/p>\n
        HTTP\/1.1 200 OK\r\nDate: Fri, 8 May 2009 11:07:02 +0000GMT\r\nContent-Type: application\/json\r\nConnection: close\r\n\r\n{\"results\":[\r\n{\"seq\":1,\"id\":\"fresh\",\"changes\":[{\"rev\":\"1-967a00dff5e02add41819138abb3284d\"}]},\r\n{\"seq\":3,\"id\":\"updated\",\"changes\":[{\"rev\":\"2-7051cbe5c8faecd085a3fa619e6e6337\"}]},\r\n{\"seq\":5,\"id\":\"deleted\",\"changes\":[{\"rev\":\"2-eec205a9d413992850a6e32678485900\"}],\"deleted\":true}\r\n],\r\n\"last_seq\":5}<\/pre>\n
        All the view parameters work on _changes, such as startkey, include_docs etc. However, note that the startkey is exclusive when applied to this view. This allows for a usage pattern where the startkey is set to the sequence id of the last doc returned by the previous query. As the startkey is exclusive, the same document won’t be processed twice.<\/p>\n
        <\/a>8. Replication<\/h2>\n
        CouchDB replication is a mechanism to synchronize databases. Much like rsync<\/i>synchronizes two directories locally or over a network, replication synchronizes two databases locally or remotely.<\/p>\n
        In a simple POST request, we tell CouchDB the source<\/em> and the target<\/em> of a replication and CouchDB will figure out which documents and new document revisions are on source<\/em> that are not yet on target<\/em>, and will proceed to move the missing documents and revisions over.<\/p>\n
        First, we will create a target database. Note that CouchDB would not automatically create a target database for us, and will return a replication failure if the target doesn\u2019t exist:<\/p>\n
        curl -X PUT http:\/\/127.0.0.1:5984\/shopcart-replica<\/pre>\n
        Now we can use the database albums-replica<\/i> as a replication target:<\/p>\n
        curl -vX POST http:\/\/127.0.0.1:5984\/_replicate -d '{\"source\":\"shopcart\",\"target\":\"shopcart-replica\"}' -H \"Content-Type: application\/json\"<\/pre>\n","protected":false},"excerpt":{"rendered":"
        This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and configure CouchDB and how to perform common operations with it. Additionally, you will build an example application from scratch and then finish the course with more …<\/p>\n","protected":false},"author":18,"featured_media":7450,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8],"tags":[108],"class_list":["post-7470","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web-development","tag-databases"],"yoast_head":"\nCouchDB: Basics and Operations - Web Code Geeks - 2026<\/title>\n<meta name=\"description\" content=\"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"CouchDB: Basics and Operations - Web Code Geeks - 2026\" \/>\n<meta property=\"og:description\" content=\"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\" \/>\n<meta property=\"og:site_name\" content=\"Web Code Geeks\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/webcodegeeks\" \/>\n<meta property=\"article:author\" content=\"http:\/\/www.facebook.com\/phlocblogger\" \/>\n<meta property=\"article:published_time\" content=\"2015-09-28T18:11:24+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2018-01-05T14:53:10+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"150\" \/>\n\t<meta property=\"og:image:height\" content=\"150\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"author\" content=\"Piyas De\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@https:\/\/twitter.com\/phloxblog\" \/>\n<meta name=\"twitter:site\" content=\"@webcodegeeks\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Piyas De\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"40 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\"},\"author\":{\"name\":\"Piyas De\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/7aab6e040a06f0dfe0d60c27768aa424\"},\"headline\":\"CouchDB: Basics and Operations\",\"datePublished\":\"2015-09-28T18:11:24+00:00\",\"dateModified\":\"2018-01-05T14:53:10+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\"},\"wordCount\":6553,\"commentCount\":0,\"publisher\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg\",\"keywords\":[\"Databases\"],\"articleSection\":[\"Web Dev\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\",\"url\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\",\"name\":\"CouchDB: Basics and Operations - Web Code Geeks - 2026\",\"isPartOf\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg\",\"datePublished\":\"2015-09-28T18:11:24+00:00\",\"dateModified\":\"2018-01-05T14:53:10+00:00\",\"description\":\"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and\",\"breadcrumb\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage\",\"url\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg\",\"contentUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg\",\"width\":150,\"height\":150},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/www.webcodegeeks.com\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Web Dev\",\"item\":\"https:\/\/www.webcodegeeks.com\/category\/web-development\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"CouchDB: Basics and Operations\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#website\",\"url\":\"https:\/\/www.webcodegeeks.com\/\",\"name\":\"Web Code Geeks\",\"description\":\"Web Developers Resource Center\",\"publisher\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.webcodegeeks.com\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#organization\",\"name\":\"Exelixis Media P.C.\",\"url\":\"https:\/\/www.webcodegeeks.com\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png\",\"contentUrl\":\"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png\",\"width\":864,\"height\":246,\"caption\":\"Exelixis Media P.C.\"},\"image\":{\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/webcodegeeks\",\"https:\/\/x.com\/webcodegeeks\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/7aab6e040a06f0dfe0d60c27768aa424\",\"name\":\"Piyas De\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/eadd6728b7b5be23f0d6585da1a953926e49c6f2369703d6cb4f1147d4dd2203?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/eadd6728b7b5be23f0d6585da1a953926e49c6f2369703d6cb4f1147d4dd2203?s=96&d=mm&r=g\",\"caption\":\"Piyas De\"},\"description\":\"Piyas is Sun Microsystems certified Enterprise Architect with 10+ years of professional IT experience in various areas such as Architecture Definition, Define Enterprise Application, Client-server\/e-business solutions.Currently he is engaged in providing solutions for digital asset management in media companies.He is also founder and main author of \\\"Technical Blogs (Blog about small technical Know hows)\\\"\",\"sameAs\":[\"http:\/\/www.phloxblog.in\",\"http:\/\/www.facebook.com\/phlocblogger\",\"http:\/\/in.linkedin.com\/in\/piyasde\",\"https:\/\/x.com\/https:\/\/twitter.com\/phloxblog\"],\"url\":\"https:\/\/www.webcodegeeks.com\/author\/piyas-de\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"CouchDB: Basics and Operations - Web Code Geeks - 2026","description":"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/","og_locale":"en_US","og_type":"article","og_title":"CouchDB: Basics and Operations - Web Code Geeks - 2026","og_description":"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and","og_url":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/","og_site_name":"Web Code Geeks","article_publisher":"https:\/\/www.facebook.com\/webcodegeeks","article_author":"http:\/\/www.facebook.com\/phlocblogger","article_published_time":"2015-09-28T18:11:24+00:00","article_modified_time":"2018-01-05T14:53:10+00:00","og_image":[{"width":150,"height":150,"url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg","type":"image\/jpeg"}],"author":"Piyas De","twitter_card":"summary_large_image","twitter_creator":"@https:\/\/twitter.com\/phloxblog","twitter_site":"@webcodegeeks","twitter_misc":{"Written by":"Piyas De","Est. reading time":"40 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#article","isPartOf":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/"},"author":{"name":"Piyas De","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/7aab6e040a06f0dfe0d60c27768aa424"},"headline":"CouchDB: Basics and Operations","datePublished":"2015-09-28T18:11:24+00:00","dateModified":"2018-01-05T14:53:10+00:00","mainEntityOfPage":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/"},"wordCount":6553,"commentCount":0,"publisher":{"@id":"https:\/\/www.webcodegeeks.com\/#organization"},"image":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage"},"thumbnailUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg","keywords":["Databases"],"articleSection":["Web Dev"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/","url":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/","name":"CouchDB: Basics and Operations - Web Code Geeks - 2026","isPartOf":{"@id":"https:\/\/www.webcodegeeks.com\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage"},"image":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage"},"thumbnailUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg","datePublished":"2015-09-28T18:11:24+00:00","dateModified":"2018-01-05T14:53:10+00:00","description":"This article is part of our Academy Course titled CouchDB \u2013 Database for the Web. This is a hands-on course on CouchDB. You will learn how to install and","breadcrumb":{"@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#primaryimage","url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg","contentUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2015\/09\/couchdb-logo-.jpg","width":150,"height":150},{"@type":"BreadcrumbList","@id":"https:\/\/www.webcodegeeks.com\/web-development\/couchdb-basics-and-operations\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.webcodegeeks.com\/"},{"@type":"ListItem","position":2,"name":"Web Dev","item":"https:\/\/www.webcodegeeks.com\/category\/web-development\/"},{"@type":"ListItem","position":3,"name":"CouchDB: Basics and Operations"}]},{"@type":"WebSite","@id":"https:\/\/www.webcodegeeks.com\/#website","url":"https:\/\/www.webcodegeeks.com\/","name":"Web Code Geeks","description":"Web Developers Resource Center","publisher":{"@id":"https:\/\/www.webcodegeeks.com\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.webcodegeeks.com\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.webcodegeeks.com\/#organization","name":"Exelixis Media P.C.","url":"https:\/\/www.webcodegeeks.com\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/","url":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","contentUrl":"https:\/\/www.webcodegeeks.com\/wp-content\/uploads\/2022\/06\/exelixis-logo.png","width":864,"height":246,"caption":"Exelixis Media P.C."},"image":{"@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/webcodegeeks","https:\/\/x.com\/webcodegeeks"]},{"@type":"Person","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/7aab6e040a06f0dfe0d60c27768aa424","name":"Piyas De","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.webcodegeeks.com\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/eadd6728b7b5be23f0d6585da1a953926e49c6f2369703d6cb4f1147d4dd2203?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/eadd6728b7b5be23f0d6585da1a953926e49c6f2369703d6cb4f1147d4dd2203?s=96&d=mm&r=g","caption":"Piyas De"},"description":"Piyas is Sun Microsystems certified Enterprise Architect with 10+ years of professional IT experience in various areas such as Architecture Definition, Define Enterprise Application, Client-server\/e-business solutions.Currently he is engaged in providing solutions for digital asset management in media companies.He is also founder and main author of \"Technical Blogs (Blog about small technical Know hows)\"","sameAs":["http:\/\/www.phloxblog.in","http:\/\/www.facebook.com\/phlocblogger","http:\/\/in.linkedin.com\/in\/piyasde","https:\/\/x.com\/https:\/\/twitter.com\/phloxblog"],"url":"https:\/\/www.webcodegeeks.com\/author\/piyas-de\/"}]}},"_links":{"self":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts\/7470","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/users\/18"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/comments?post=7470"}],"version-history":[{"count":0,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/posts\/7470\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/media\/7450"}],"wp:attachment":[{"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/media?parent=7470"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/categories?post=7470"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webcodegeeks.com\/wp-json\/wp\/v2\/tags?post=7470"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}