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}) {
emit(...)
}
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 <[email protected]>wrote:
>
>> On 14. November 2013 at 20:45:55, Ryan Mohr ([email protected]) wrote:
>>>
>>> The show/list thread (posted by [email protected]) 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:
>>> http://insideintercom.io/product-strategy-means-saying-no/
>>> http://zurb.com/article/744/steve-jobs-innovation-is-saying-no-to-1-0
>>
>> 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
>>
>>
