Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Idea for better handling of emit function #323

Closed
MrBigDog2U opened this issue Jan 2, 2013 · 1 comment
Closed

Idea for better handling of emit function #323

MrBigDog2U opened this issue Jan 2, 2013 · 1 comment

Comments

@MrBigDog2U
Copy link

I didn't see an area where suggestions could be contributed (is there such a place) so I am putting this here. I don't know if there is a formal API to which pouch is being developed and, if there is and the following change is not compatible, then feel free to close this.

I noticed in the query logic, there is a function method called "emit" that the querying code is supposed to call in order to add the document under consideration to the view. There is some additional code with the following comment

// ugly way to make sure references to 'emit' in map/reduce bind to the
// above emit

It seems a more elegant way to accomplish this same thing is to actually pass the "emit" function as an argument to the map/reduce function - in effect, a callback to the callback. That way, there is no risk that the map/reduce function inadvertently gets bound to to the wrong emit method. It also removes the "ugly" binding hack.

@daleharvey
Copy link
Member

Issues are a perfect place to suggest things like this, thanks

The 'formal' API is pretty much what is documented at https://github.com/daleharvey/pouchdb/blob/master/docs/api.md

The current code for map reduce functionality is only in there for compatibility with CouchDB map reduce views, and changing the syntax of the map reduce functions would break that compatibility

The mapreduce code is fairly well uncoupled from the rest of the database code and the plan is to have various query plugins that may have nicer syntax etc, but the mapreduce one has to be kept as is for compatibility

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants