Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of dave@muse.net.nz designates
 209.85.161.180 as permitted sender)
MIME-Version: 1.0
Date: Fri, 8 Apr 2011 14:55:07 +1200
Message-ID: <BANLkTim67x=OS0mwMvdYF9xiF+=dzNu1=Q@mail.gmail.com>
Subject: do we support broken javascript in views and lists?
From: Dave Cottlehuber <dave@muse.net.nz>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

On IRC, rnewson raised a point which merits wider discussion than just those
people who love to read JIRA notifications... original issue was
https://issues.apache.org/jira/browse/COUCHDB-1122 .

If an error occurs in a view (or list) there is no feedback to the
HTTP requester
that this has happened other than unexpected close of connection.  The HTTP
status code is 200 which is not ideal. JS errors are only visible in system logs
which may not be easily available to hosted couch users.

* About to connect() to muse.net.nz port 5984 (#0)
*   Trying 192.168.1.68... connected
* Connected to muse.net.nz (192.168.1.68) port 5984 (#0)
> GET /testy/_design/bug/_list/test/empty HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> Host: muse.net.nz:5984
> Accept: */*
>
< HTTP/1.1 200 OK
< Vary: Accept
< Transfer-Encoding: chunked
< Server: CouchDB/1.1.1 (Erlang OTP/R14B)
< Etag: "70F0CJ1DZ75N2D8QPOROVI5G7"
< Date: Fri, 08 Apr 2011 01:17:06 GMT
< Content-Type: application/json
<
* Received problem 2 in the chunky parser
* Closing connection #0
curl: (56) Received problem 2 in the chunky parser

Putting aside the case of a view or list that doesn't handle a small # of docs
correctly, this is really about how we manage and communicate back large
numbers of failures either in the view (in the b-tree) or in the list (runtime).

I think there's 3 points;

#1 Should CouchDB handle gracefully JavaScript errors or not, in principle?
This is really about performance impact of repeated failures, and from
the user's
perspective receiving no data in the view. Personally I'm for not being graceful
and ensuring we can pass that failure via the HTTP API.

#2 How can we manage errors in views better?
These are precomputed and could be stored in the view _info resource
http://techzone.couchbase.com/sites/default/files/uploads/all/documentation/couchbase-api-design.html#couchbase-api-design_db-design-designdoc-info_get

[2011/04/07 -:- 11:42:17 PM] <dch> rnewson: impossible yes. so for
lists the question is how best to return the error back from couchjs
without buggering up data that might already have been sent. is there
no http "footer" or status code ?
[2011/04/07 -:- 11:42:45 PM] <+rnewson> dch: there are http footers,
yes. not well supported, though.
[2011/04/07 -:- 11:42:49 PM] <+jan____> there is but nobody supports it
[2011/04/07 -:- 11:43:24 PM] <+rnewson> dch: I think it can't be added
to the view result., but we can add it to the view info resource. the
one that shows doc_count, update_seq, etc.
[2011/04/07 -:- 11:43:33 PM] <+rnewson> "exception_count":0, for example.
[2011/04/07 -:- 11:43:42 PM] <+rnewson> "lameness":"90%"
[2011/04/07 -:- 11:50:50 PM] <+jan____> rnewson, yeah, that'd work
[2011/04/07 -:- 11:51:18 PM] <+rnewson> jan____: sounds feasible and
useful, right?
[2011/04/07 -:- 11:52:15 PM] <+jan____> yeah

#3 how can we manager errors in lists better?
These are not precomputed, although the list they're consuming is.
Any ideas on a solution?

A+
Dave