couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith <gar...@apache.org>
Subject Re: [PROPOSAL] Deprecate global functions in query server
Date Wed, 02 Dec 2015 13:01:14 GMT
Ok you make good points and I wasn’t aware of all these functions http://docs.couchdb.org/en/1.6.1/query-server/javascript.html
<http://docs.couchdb.org/en/1.6.1/query-server/javascript.html>
I’m going to do one more bike shed and then I will leave it up to you and other people who
actually want to implement this. 
For the case of map reduce, I would go with a function call like I said before

function (doc, emit) {

}

Then for all our other helpers I would make them available through a require. This in my mind
makes it similar to node.js or to a browser if you use browserify, web pack, requirejs etc
So a full example would be

function (doc, emit) {
   var isArray = require(‘helpers’).isArray;
   var allHelpers = require(‘helpers’);


}

That is my 2 cents worth.

Cheers
Garren

> On 02 Dec 2015, at 2:42 PM, Alexander Shorin <kxepal@gmail.com> wrote:
> 
> Hi Garren,
> 
> On Wed, Dec 2, 2015 at 3:35 PM, Garren Smith <garren@apache.org> wrote:
>> 
>> This is an interesting idea. I think passing the emit function in is a good idea
and might make somethings easier in PouchDB. I would rather a  map function looked something
like this
>> 
>> function (doc, emit) {
>> 
>> }
> 
> That's nice, but won't work: map function has access to a lot of other
> global functions we provide, so you'll end with signature of 7
> arguments.  I don't think there is any reason to fix this problem by a
> half. Just fix all globals or no one.
> 
>> I don’t like the idea of passing a userCtx object. That feels overly bulky. Things
like JSON/require are global variables in Node.js or the browser so my feeling is to follow
their lead on those.
> 
> ctx referenced not to userCtx, but a generic context object that hold
> all the global function and objects we provide now. These are listed
> in reference on documentation. May be we can find a better name to not
> cause confusion. funcs? env? Suggestions welcome (:
> 
> --
> ,,,^..^,,,


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