[
https://issues.apache.org/jira/browse/COUCHDB-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15866642#comment-15866642
]
Norbert Nemec commented on COUCHDB-3280:
----------------------------------------
Indeed, your comments capture the idea perfectly.
I don't know much about the implementation of map-reduce vs. Mango. My
inspiration orginally came from PouchDB where it is already nearly possible to
use a pouch-find query on top of a design document containing some logic in
JavaScript. In that case, the implementation effort is mostly smoothing out
some API details and documenting the feature.
> Computed Indices in Mango Query Server
> --------------------------------------
>
> Key: COUCHDB-3280
> URL: https://issues.apache.org/jira/browse/COUCHDB-3280
> Project: CouchDB
> Issue Type: Wish
> Components: Mango
> Reporter: Norbert Nemec
>
> The Mango Query Server aims at offering a simpler alternative to MapReduce
> queries. As it stands now, it is also fundamentally limited in terms of
> expressiveness an performance. Indices can be defined only over a plain set
> of fields with none of the possibilities that a map function offers.
> Selectors allow powerful combinations, but require to perform much of the
> computational effort at query time. The $regex operator, for example even
> contains a warning about this in the documentation.
> My proposal would be to add an alternative way to define indices by
> explicitly providing a design document map function. The 'fields' argument of
> such a "computed index" would not have to exist as an actual field in the
> database, but would be made available as a "computed field" for regular use
> in subsequent find requests.
> Ultimately, this approach would bridge the gap between the simple-but-limited
> Mango queries and the powerful-but-unwieldy MapReduce queries. Rather than
> having to decide between both approaches, developers could start with the
> simple Mango approach and then just learn one more concept if they need the
> full power.
> (It is my understanding that the currently recommended approach is to add
> computed fields to the documents directly at creation time. Though this is a
> workaround for the limitations of selectors, it does not offer any guarantees
> for internal consistency of a database and mixes the concerns of content
> creation with those of retrieval.)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
