Translate CouchDB javascript views to erlang

Question

I need some help with translating the following CouchDB views from javascript to erlang. I need them in erlang, because in javascript the view uses all of the available stack memory and crashes couchjs (see this bugreport https://issues.apache.org/jira/browse/COUCHDB-893).

The current map functions I have in javascript are:

sync/transaction_keys

function(doc) {
  if(doc.doc_type == "Device") {
      for(key in doc.transactions)
          emit(key, null);
  }
}

and sync/transcation

function(doc) {
  if(doc.doc_type == "Device") {
      for(key in doc.transactions) {
          t = doc.transactions[key];
          t.device = doc.device;
          emit(key, t);
     }
  }
}

An example document would be:

{
   "_id": "fcef7b5c-cbe6-31af-8363-2b446a7e4cf2",
   "_rev": "3-c90abd075404a75744fd3e5e4f04ebad",
   "device": "fcef7b5c-cbe6-31af-8363-2b446a7e4cf2",
   "doc_type": "Device",
   "transactions": {
       "79fe8630-c0c0-30c6-9913-79b2f93e3e6e": {
           "timestamp": 1309489169533,
           "version": 10008,
           "some_more_data" : "more_data"
       }
       "e4678930-c465-76a6-8821-75a3e888765a": {
           "timestamp": 1309489169533,
           "version": 10008,
           "some_more_data" : "more_data"
       }
   }
}

Basically sync/transaction_keys emits all keys of the transaction dictionary and sync/transaction does emit all entries in the transaction dictionary.

Unfortunately I never used Erlang before and I need to rewrite that code pretty soon, so any help is very welcomed.

Thanks in advance.

How many transactions do you have in your larger documents? That should be OK, though I'd avoid global variables (I don't think that really matters in this case). — Dustin
about 594 transactions/document. But it keeps growing because each 15min another transaction will be added. — Simon
Perhaps you'd be better off representing these transactions as new documents. Is there any reason not to do that? It seems like it'd be easier to model this that way. — Dustin
Yeah, that's what I did before, but I was told to change it to 1 document/device. — Simon

Dustin Dustin · Accepted Answer · 2011-07-23T19:29:21

I just did your second one (the more complicated one). The first can easily be extrapolated from there:

fun({Doc}) ->
        %% Helper function to get a toplevel value from this doc.
        F = fun(B) -> proplists:get_value(B, Doc) end,
        %% switch on doc type
        case F(<<"doc_type">>) of
            <<"Device">> ->
                %% Grab the transactions from this document
                {Txns} = F(<<"transactions">>),
                lists:foreach(fun({K,V}) ->
                                      %% Emit the key and the value as
                                      %% the transaction + the device
                                      %% id
                                      {T} = proplists:get_value(K, Txns),
                                      Emit(K, {[{<<"device">>, F(<<"device">>)} | T]})
                              end,
                             Txns);
            _ -> false %% Not a device -- ignoring this document
        end
end.

Translate CouchDB javascript views to erlang

1 Answers