couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Lowery <>
Subject Re: Product management means saying no
Date Fri, 15 Nov 2013 18:03:19 GMT
I'll chime in here as a fairly fresh CouchDB user, so TIFWIW:

What I would like is the ability to specify a view that takes a key/value map.  Behind that
view would be indexes for n number of k-v pairs in that map in any permutation order. E.g.:

function(doc, {keynames: ['shape', 'size', 'color'], permute: 2}) {

which would generate 6 views ( [shape, size], [shape, color], [size, shape], [size,color],
[color, shape], [color, size] ) which would be used to access via index a subset of docs,
then filter based on the third key-value, if any.  It would choose which index to use based
on the least # of docs in each view.

I realize that the permute param results in a factorial # of views (permuting 5 k-v pairs
= 120 views); what is the practical limit?  I assume it would depend on the # of documents
in a db.

Jini does something like this (API-wise), but it's for config management and not really designed
for high-performance.

-- Jeff

On Nov 15, 2013, at 1:03 AM, Stanley Iriele wrote:

> Interesting read...
> One of the reasons I like CouchDB so much is that it kind of transcends the
> traditional notion of a database with http web server like capabilities
> that allow for some very interesting architectures. Moving that around and
> trying to shift it in either direction would make it "like its
> competitors"....I think It should remain as is truth be told. There are
> some things that need to be enhanced..and perhaps adding plugins could be
> cleaner.
> @Dave CouchApps aside, I think CouchDB is just as much one as it is the
> other. I recently used the OS Deamons functionality with proxying for a
> little reverse proxy action and I can't tell how slick it was. When I
> showed my coworkers what was going on they the re-occuring theme was .."It
> can do that too?"..Why yes...yes it can :-D
> On Fri, Nov 15, 2013 at 12:49 AM, Dave Cottlehuber <>wrote:
>> On 14. November 2013 at 20:45:55, Ryan Mohr ( wrote:
>>> The show/list thread (posted by recently
>>> sparked an
>>> interesting debate. Like Joan, I too feel that CouchDB tries
>>> to handle way
>>> more than it should. (Caveat -- I actually take this stance to
>>> the extreme
>>> believing that the couchapp behavior and utilities like futon/fauxton
>>> shouldn't be included in the core installation.)
>>> IMO the show/list behavior is an application concern, not a database
>>> concern, and should be handled by the application server or client.
>>> If you
>>> think of CouchDB as your database and your application server
>>> the line
>>> quickly gets blurry.
>>> I'm curious, where does the dev team draw the line on couchdb's
>>> responsibilities? The fact that it's already an api+database+services
>>> suggests there won't be any concrete boundaries. All must be
>>> by design.
>>> Some related articles:
>> Good links.
>> Personally, I like the idea of a lean core, comprising k/v b-tree store on
>> disk + replication. And pretty much everything else as plugin/extensions.
>> For me, CouchDB is JSON docs + attachments, with streaming HTTP API for
>> docs, attachments, views/db, changes, security authorisation  +
>> replication. I think the rest could be taken out — plugins, incl show/list
>> and authentication.
>> CouchApps are a unique feature but in principle can be added to any db
>> that supports HTTP, arbitrary binary blobs & mime content type. It’s just
>> that with couch’s other features its just so yummy. I still love the fact
>> that the whole iriscouch website is a single couchdb document. That’s
>> awesome.
>> Maybe an appropriate objective for the project post merge completion?
>> A+
>> Dave

View raw message