couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Kocoloski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-2176) Map/Reduce views within views
Date Thu, 27 Feb 2014 19:33:19 GMT

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

Adam Kocoloski commented on COUCHDB-2176:
-----------------------------------------

It's been discussed a number of times on the dev@ list dating all the way back to 2009, but
I'm not aware of any pre-existing JIRA ticket.  It's a significant effort; some good news
is that the work [~benoitc] did on adding sequence indexes to views is quite likely foundational
for this feature.

> Map/Reduce views within views
> -----------------------------
>
>                 Key: COUCHDB-2176
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2176
>             Project: CouchDB
>          Issue Type: Wish
>      Security Level: public(Regular issues) 
>            Reporter: Nolan Lawson
>
> I don't know if this has already been discussed, but often with CouchDB I've run into
a situation where a single map/reduce view couldn't quite slice my data in the way I needed.
> For instance, say you want to order rows by the _value_ of an emit function, rather than
the key.  E.g., you want to emit a certain key, reduce it using {{_count}}, and then order
that output by the counts.  Currently you'd have to stuff the output of the first view into
another database (manually) and then create a new view on top of that one.
> It's also pretty common for apps to have different flavors of "detail/summary" views,
each one optimized for a different page on the web site (e.g. "my inbox", "message summary",
"message with details/attachments", "message thread", etc.).  In the past I've simply resorted
to redundancy, uploading the same data represented in different ways but all as documents
in separate databases, but this is a pain to manage.
> Instead, I'd love it if the input of one view could simply be the output of another view.
 This would create endless flexibility and obviate the need for a lot of tinkering with the
emit values (e.g. with linked documents).  I'm not sure what the complexity would be of introducing
this into the CouchDB code, but from a user's point of view it would definitely be nice to
have.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message