{"action":"created","issue":{"url":"https://api.github.com/repos/kofrasa/mingo/issues/14","labels_url":"https://api.github.com/repos/kofrasa/mingo/issues/14/labels{/name}","comments_url":"https://api.github.com/repos/kofrasa/mingo/issues/14/comments","events_url":"https://api.github.com/repos/kofrasa/mingo/issues/14/events","html_url":"https://github.com/kofrasa/mingo/issues/14","id":70139811,"number":14,"title":"Feature request: defining custom Operators.","user":{"login":"jorisvddonk","id":266543,"avatar_url":"https://avatars.githubusercontent.com/u/266543?v=3","gravatar_id":"","url":"https://api.github.com/users/jorisvddonk","html_url":"https://github.com/jorisvddonk","followers_url":"https://api.github.com/users/jorisvddonk/followers","following_url":"https://api.github.com/users/jorisvddonk/following{/other_user}","gists_url":"https://api.github.com/users/jorisvddonk/gists{/gist_id}","starred_url":"https://api.github.com/users/jorisvddonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jorisvddonk/subscriptions","organizations_url":"https://api.github.com/users/jorisvddonk/orgs","repos_url":"https://api.github.com/users/jorisvddonk/repos","events_url":"https://api.github.com/users/jorisvddonk/events{/privacy}","received_events_url":"https://api.github.com/users/jorisvddonk/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":6,"created_at":"2015-04-22T14:20:39Z","updated_at":"2015-04-27T11:02:51Z","closed_at":null,"body":"One thing I find myself wishing for when using Mingo is the ability to define custom operators.\r\n\r\nWithout the ability to define custom operators, I find myself wrapping aggregators in my own functions with aggregator-like APIs so that I can perform unsupported mutations or actions on data in such a way that the logic is centralized in my application and I don't repeat myself needlessly. If given the ability to define custom operators, the need for wrapping of Mingo's core functions in other functions may remove itself, and Mingo can be used as an implementation of a domain specific language that's very MongoDB-like.\r\n\r\nI've given a look at the source code, and it appears that exposing the Ops and *Operators objects via a nice API should do the trick. Of course, users of the extension API need to realize that they might break things severely, but ensuring that they don't would be their own responsibility.\r\n\r\nI was wondering what your thoughts were on this. Do you think this is within scope of the project?\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/kofrasa/mingo/issues/comments/96610397","html_url":"https://github.com/kofrasa/mingo/issues/14#issuecomment-96610397","issue_url":"https://api.github.com/repos/kofrasa/mingo/issues/14","id":96610397,"user":{"login":"jorisvddonk","id":266543,"avatar_url":"https://avatars.githubusercontent.com/u/266543?v=3","gravatar_id":"","url":"https://api.github.com/users/jorisvddonk","html_url":"https://github.com/jorisvddonk","followers_url":"https://api.github.com/users/jorisvddonk/followers","following_url":"https://api.github.com/users/jorisvddonk/following{/other_user}","gists_url":"https://api.github.com/users/jorisvddonk/gists{/gist_id}","starred_url":"https://api.github.com/users/jorisvddonk/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jorisvddonk/subscriptions","organizations_url":"https://api.github.com/users/jorisvddonk/orgs","repos_url":"https://api.github.com/users/jorisvddonk/repos","events_url":"https://api.github.com/users/jorisvddonk/events{/privacy}","received_events_url":"https://api.github.com/users/jorisvddonk/received_events","type":"User","site_admin":false},"created_at":"2015-04-27T11:02:51Z","updated_at":"2015-04-27T11:02:51Z","body":"I like your proposal of passing in the Mingo internals via a function argument. That should keep things neat and tidy.\r\n\r\nOne point of critique I have with regards to your proposed `addOperator` function: the function you pass in to it should return an object containing a single key as per your example, but it's not really made clear what happens if an object with more than 1 key is returned instead. I'd propose either renaming the function to `addOperators`, allowing for the registering of multiple operators in one go, or having the inner function (the one where `m` is passed into) return something like `{name: '$between', type: 'pipeline', func: function (...) {...}}` instead, thus forcing and making it clear that only a single operator can be added with each call of `addOperator`.\r\n\r\nRegarding overriding existing operators: maybe it's indeed better if existing operators can't be overridden."}}