1.5.1. /{db}/_design/{ddoc}

HEAD /{db}/_design/{ddoc}

Returns the HTTP Headers containing a minimal amount of information about the specified design document.

See also

HEAD /{db}/{docid}

GET /{db}/_design/{ddoc}

Returns the contents of the design document specified with the name of the design document and from the specified database from the URL. Unless you request a specific revision, the latest revision of the document will always be returned.

See also

GET /{db}/{docid}

PUT /{db}/_design/{ddoc}

The PUT method creates a new named design document, or creates a new revision of the existing design document.

The design documents have some agreement upon their fields and structure. Currently it is the following:

  • language (string): Defines Query Server to process design document functions

  • options (object): View’s default options

  • filters (object): Filter functions definition

  • lists (object): List functions definition. Deprecated.

  • rewrites (array or string): Rewrite rules definition. Deprecated.

  • shows (object): Show functions definition. Deprecated.

  • updates (object): Update functions definition

  • validate_doc_update (string or object): Validate document update JavaScript function source, or Mango selector

  • views (object): View functions definition.

  • autoupdate (boolean): Indicates whether to automatically build indexes defined in this design document. Default is true.

Note, that for filters, lists, shows and updates fields objects are mapping of function name to string function source code. For views mapping is the same except that values are objects with map and reduce (optional) keys which also contains functions source code.

See also

PUT /{db}/{docid}

DELETE /{db}/_design/{ddoc}

Deletes the specified document from the database. You must supply the current (latest) revision, either by using the rev parameter to specify the revision.

See also

DELETE /{db}/{docid}

COPY /{db}/_design/{ddoc}

The COPY (which is non-standard HTTP) copies an existing design document to a new or existing one.

Given that view indexes on disk are named after their MD5 hash of the view definition, and that a COPY operation won’t actually change that definition, the copied views won’t have to be reconstructed. Both views will be served from the same index on disk.

See also

COPY /{db}/{docid}

1.5.2. /{db}/_design/{ddoc}/{attname}

HEAD /{db}/_design/{ddoc}/{attname}

Returns the HTTP headers containing a minimal amount of information about the specified attachment.

See also

HEAD /{db}/{docid}/{attname}

GET /{db}/_design/{ddoc}/{attname}

Returns the file attachment associated with the design document. The raw data of the associated attachment is returned (just as if you were accessing a static file.

See also

GET /{db}/{docid}/{attname}

PUT /{db}/_design/{ddoc}/{attname}

Uploads the supplied content as an attachment to the specified design document. The attachment name provided must be a URL encoded string.

See also

PUT /{db}/{docid}/{attname}

DELETE /{db}/_design/{ddoc}/{attname}

Deletes the attachment of the specified design document.

See also

DELETE /{db}/{docid}/{attname}

1.5.3. /{db}/_design/{ddoc}/_info

GET /{db}/_design/{ddoc}/_info

Obtains information about the specified design document, including the index, index size and current status of the design document and associated index information.

Parameters:

  • db – Database name

  • ddoc – Design document name

Request Headers:

  • Accept –

    • application/json

    • text/plain

Response Headers:

  • Content-Type –

    • application/json

    • text/plain; charset=utf-8

Response JSON Object:
Status Codes:

Request:

GET /recipes/_design/recipe/_info HTTP/1.1
Accept: application/json
Host: localhost:5984

Response:

HTTP/1.1 200 OK
Cache-Control: must-revalidate
Content-Length: 263
Content-Type: application/json
Date: Sat, 17 Aug 2013 12:54:17 GMT
Server: CouchDB (Erlang/OTP)

{
    "name": "recipe",
    "view_index": {
        "updates_pending": {
            "minimum": 0,
            "preferred": 0,
            "total": 0,
            "maximum": 0,
            "copies": 6,
            "copies_expected": 6
        },
        "compact_running": false,
        "language": "python",
        "purge_seq": 0,
        "signature": "a59a1bb13fdf8a8a584bc477919c97ac",
        "sizes": {
          "active": 926691,
          "disk": 1982704,
          "external": 1535701
        },
        "update_seq": 12397,
        "updater_running": false,
        "waiting_clients": 0,
        "waiting_commit": false
    }
}

1.5.3.1. View Index Information

The response from GET /{db}/_design/{ddoc}/_info contains view_index (object) field with the next structure:

  • compact_running (boolean): Indicates whether a compaction routine is currently running on the view

  • sizes.active (number): The size of live data inside the view, in bytes

  • sizes.external (number): The uncompressed size of view contents in bytes

  • sizes.file (number): Size in bytes of the view as stored on disk

  • language (string): Language for the defined views

  • purge_seq (number): The purge sequence that has been processed

  • signature (string): MD5 signature of the views for the design document

  • update_seq (number / string): The update sequence of the corresponding database that has been indexed

  • updater_running (boolean): Indicates if the view is currently being updated

  • waiting_clients (number): Number of clients waiting on views from this design document

  • waiting_commit (boolean): Indicates if there are outstanding commits to the underlying database that need to processed

  • updates_pending (object): Information about the pending updates for this index calculated over all available copies of all the shards.

    • minimum (number): Backlog of the most up to date copy of each range. 0 means at least one complete copy exists for every range.

    • preferred (number): Backlog of the preferred shard copies, the ones queries are routed to by default.

    • total (number): Backlog over all copies added up.

    • maximum (number): Backlog of the least up to date copy of each range. 0 means the index is fully built on every copy.

    • copies (number): The number of shard copies which reported an answer. Copies which are unreachable or in maintenance mode are not included. Compare with the copies_expected number.

    • copies_expected (number): Expected number of shard responses. If copies is smaller than this, the results may be partial and maximum for instance may not represent the true backlog.

    Changed in version 3.6: Information is now gathered from every shard copy instead of the first responding copy of each range. maximum, copies and copies_expected were added and total now adds up all copies.