Nick Vatamaniuc created COUCHDB-2818:
----------------------------------------
Summary: Design documents accept invalid views
Key: COUCHDB-2818
URL: https://issues.apache.org/jira/browse/COUCHDB-2818
Project: CouchDB
Issue Type: Bug
Security Level: public (Regular issues)
Components: Database Core, Documentation, JavaScript View Server
Reporter: Nick Vatamaniuc
Design documents seem to accept invalid views.
For example:
{code}
$ http PUT $DB1/db2/_design/des1 views:='{ "v1" : "function(d){emit(d._id,d);}"
}'
HTTP/1.1 201 Created
{
"id": "_design/des1",
"ok": true,
"rev": "1-04701f13eb827265c442d219bd995e91"
}
{code}
Going by the documentation for design documents:
http://docs.couchdb.org/en/latest/api/ddoc/common.html#put--db-_design-ddoc , a
view should be an object that has a map (a string) and an optional reduce
(string).
Interestingly some validation is performed to check that views field itself is
an object. For example:
{code}
$ http PUT $DB1/db2/_design/des1 views:='"x"'
HTTP/1.1 400 Bad Request
{
"error": "invalid_design_doc",
"reason": "`views` parameter must be an object."
}
{code}
Also there is a deeper level validation of map functions:
{code}
$ http PUT $DB1/db2/_design/des1 views:='{ "m":{"map":""} }'
{
"error": "not_found",
"reason": "missing function"
}
{code}
If there is interest, I have a patch that, if provided: views, filters, lists,
show, updates, options are objects. rewrites are arrays, validate_doc_update
and language are strings.
Then if views is provided, each view is an object. It must have a map function
(a string) and an optional reduce function (also a string).
Here is an example how it works:
{code}
$ http PUT $DB1/db2/_design/des1 views:='{ "m":"bad" }'
HTTP/1.1 400 Bad Request
{
"error": "invalid_design_doc",
"reason": "View m must be an object"
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
