[jira] [Updated] (COUCHDB-2176) Map/Reduce views within views

["Nolan Lawson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COUCHDB-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nolan Lawson updated COUCHDB-2176:
----------------------------------

    Description: 
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.

  was:
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.


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