couchdb-erlang mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Cottlehuber <>
Subject Re: Tips for debugging erlang view/updates/ etc.
Date Mon, 11 Nov 2013 10:09:09 GMT

On 07. November 2013 at 11:01:35, Mike Marino ( wrote:
> Hi all,

Hey Mike,

Welcome :-)

Here’s what I would do:

1) remember everything’s a function, so we can pull data structures and functions out of
couchdb and play with them separately.

2) you can log into the couch/erlang console directly and execute code

3) there’s nothing stopping you in your erlang map fn to doing naughty things like logging.
This is why they’re disabled by default - you have the whole VM to fiddle with.

> I have recently been working on migrating from Javascript to  
> erlang
> for views and I was wondering if there are any tips that folks have  
> for debugging this code? I have used:
> 1. ... the couch log to decipher crashes, but some of this
> information is difficult to parse and sometimes lacking information 

> (e.g. it just says the view crashed, instead of saying "where"  
> or
> "what”).

That would be a good patch to work on! If you run in debug mode, you’ll likely see enough
to figure out what the issue is, or at least where the view rebuild crashes.

I think that when the view fails, you should be able to query it to see the seq num, and then
match that to the same seqnum in the db. Or you can query the view, descending=1, limit=1
and see the prior doc. I leave that as an exercise to the reader ;-).

> 2. ... the erl command line for testing code/compilation, etc. 

You can pull out the contents of a doc using couchbeam[1] but that’s no fun / too easy.

{ok, Db} = couch_db:open_int(<<"testy">>, []).
{ok, Doc} = couch_db:open_doc(Db, <<“foo">>).
Body = couch_doc:with_ejson_body(Doc).

I think (not tested) that you can plug that body directly into your map function. If not,
it should be pretty close.
> I am curious if others have found a good workflow for dealing with 
> this.
> Cheers,
> Mike

In terms of workflow, here’s some wooly thinking, maybe somebody has a better idea.

- run a plain erlang vm, with sync[2] loaded so your modules auto-reload & recompile when
the source is saved.
- do a simple wrapping module around your map function so there’s a proper module for the
vm to load.
- have a list with some sample doc bodies in it already.
- use `c(your-module-name).` in the console to load it up.
- then wrapper:map(Doc) to test, and map(Fun, List_of_Docs) for more testing

You can get fancier and turn this into a test module, e.g.,
that would be the right way to do it.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message