1.5.1. /db/_design/design-doc — Apache CouchDB® 3.2 Documentation

# 1.5.1. `/db/_design/design-doc`

`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): Validate document update function source
  - 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/design-doc/attachment`

`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/design-doc/_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:
  | name (string) – Design document name view_index (object) – View Index Information
  Status Codes: | 200 OK – Request completed successfully

  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": {
              "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