[<<"index">>],<<"\\&CouchDB::AppServ:: Docclass::map_doctype #version=19">>,
doesn't look quite right to me. Could you friendpaste/gist your design document? FYI: If you try uploading your design document to Cloudant you'll get an error message if it's malformed or the map/reduce code does not compile. I think we're porting that work as part of the merge, or shortly after. B. On 22 March 2013 08:38, Dave Cottlehuber <[email protected]> wrote: > On 22 March 2013 09:20, Dave Cottlehuber <[email protected]> wrote: >> On 22 March 2013 06:16, Gerald Richter - ECOS <[email protected]> wrote: >>> Hi, >>> >>> >>> I am using couchdb for over two years now and I really love it, but I hate >>> it’s error messages. If there is one thing I would wish that should be in >>> the next release, than it would be: human readable error messages. I know >>> that writing good error messages is nothing that programmer likes to do. We >>> like more to implement great new features, but for the daily work having a >>> good diagnostic message is of so much value and saves so much time… >> >> Good call, maybe you want to open a JIRA for this and we can discuss >> what needs to change? >> >>> So in addition to the many hour I spend in the past, trying to decrypt an >>> error message of couchdb, here is one that really gives me no clue what it >>> is about and I am giving up. Neither starting couchdb with debug output, >>> nor looking at the output of my viewserver, shows anything irregular. >>> Basically a view index is rebuild and it crashes somewhere in the middle of >>> the process with the error message below. I hope somebody on the list, >>> could shed some light what’s going on here. >> >> If you can run the view build with log level = debug and send a link >> to the results we might see something more interesting. >> >> Don't forget what version of erlang, and couch you are running. >> >> I'm pretty sure one of these fields in that log excerpt will tell you >> the last doc processed but I don't see it right now myself. >> >> If your view is small, you might consider sprinkling in some log >> messages http://wiki.apache.org/couchdb/HTTP_view_API#Debugging_Views >> bearing in mind there's a *significant* performance impact for doing >> this. >> >> If your view is failing at the same place each time, you'll see this >> when you delete the view, re-run the build, query _info (see below) >> and then re-run the build and re-query _info again. >> >> http://wiki.apache.org/couchdb/HTTP_view_API?action=show&redirect=HttpViewApi#Getting_Information_about_Design_Documents_.28and_their_Views.29 > > I forgot the most important bit (aaugh), in that view _info output is > the update_seq which should match the db's info at > $COUCH:5984/dbname/ if it completed all docs. If it didn't you should > be able to GET $COUCH:5984/dbname/_changes?since=<update_seq> and one > of the docs around there should be the culprit. You can use > limit=5&descending=true as well to get a list of the preceding docs, > and just limit=5 to get subsequent doc ids. I'm not 100% sure that > this all will work, maybe one of the other devs can confirm, as there > are a few circumstances[1] where the update_seq might not match > between view & db, but it should be reasonably close. > > http://wiki.apache.org/couchdb/HTTP_view_API#Querying_Options > > [1] https://issues.apache.org/jira/browse/COUCHDB-1367 > > A+ > Dave
