[jira] [Commented] (COUCHDB-3280) Computed Indices in Mango Query Server

["Tony Sun (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COUCHDB-3280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15859149#comment-15859149 ] 

Tony Sun commented on COUCHDB-3280:
-----------------------------------

Hi [~NdotNdot],

    Thanks for this interesting proposal! As you know, the map-reduce indexing code path utilizes the javascript engine to compile and execute on a document in order to build the underlying views. For mango, the code path relies on the couch native process codepath to create the underlying view. The differentiator in the design doc that chooses which code path for indexing is "language" ("javascript" vs "query"). 

   If I understand correctly, you're envisioning the use case such that even when the design doc's language is "query", we still provide the user the ability to write a map function that leverages the power of the javascript engine? 

Thanks for clarifying! 

Tony

> 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)