On 07. November 2013 at 11:01:35, Mike Marino ([email protected]) 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.
rr("/repos/couch/git/src/couchdb/*.hrl").
rr("/repos/couch/git/src/couch_mrview/include/*.hrl").
{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.
http://learnyousomeerlang.com/eunit, that would be the right way to do it.
A+
Dave
[1]: http://benoitc.github.io/couchbeam/
[2]: https://github.com/rustyio/sync
