couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Dionne <>
Subject Re: Help shape the future of CouchDB: your voice needed!
Date Thu, 19 Apr 2012 11:26:15 GMT

I'd be interested in your thoughts on this. Damien presented the UnQL stuff to us, some time
ago before he left the CouchDB project, and I thought then it was overly ambitious. 

I agree that SQL is awesome and hard to get away from after thinking in terms of relations
for years. I'd love to see an alternative to SQL that was a better fit for document stores,
that takes into account that document are sorts of like objects with attributes. There was
considerable work done in this area years ago by folks working in  functional dbs. 

Let us know what you think after you've played around with MR.


On Apr 19, 2012, at 6:51 AM, Mike Kimber wrote:

> Robert,
> I might just do that :-). To be honest I've just inherited a our couchdb project and
have little experience with it at the moment (just been trying to get it upgraded etc to-date),
So once I've actually written a few MR I'll be in e better place to provide some sensible
> However one generic NoSQL observation i.e. no just Couchdb is that despite NoSQL being
well "No SQL", Google with Dremel ( ) and Facebook
with Hive have actually put a SQL like interface on top of their Big data platforms, so like
it or not that SQL syntax is proving hard to kick.
> Mike 
> -----Original Message-----
> From: Robert Newson [] 
> Sent: 18 April 2012 14:11
> To:
> Subject: Re: Help shape the future of CouchDB: your voice needed!
> Not as yet, it's more a recognition that we should work on it than a
> full-fledged solution. Why not start a thread with some ideas?
> B.
> On 18 April 2012 14:06, Mike Kimber <> wrote:
>> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap list might
>> Mike
>> -----Original Message-----
>> From: Robert Newson []
>> Sent: 18 April 2012 14:02
>> To:
>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>> I don't see UNQL appearing on CouchDB's roadmap.
>> B.
>> On 18 April 2012 13:44, Mike Kimber <> wrote:
>>> One thing I did not see on the roadmap was UNQL:
>>> Is this covered by  Simpler Querying?
>>> Is UNQL still something that interests Couchdb and if so what sort time frame
are we talking?
>>> Thanks
>>> Mike
>>> -----Original Message-----
>>> From: Alon Keren []
>>> Sent: 16 April 2012 21:28
>>> To:
>>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>> Thank you guys for making this poll, and for publishing the minutes and
>>> audio.
>>> I've voted, and it would be really nice to have this (or other) list as a
>>> wish-list that couchdb users could continuously update.
>>>  Alon
>>> On 16 April 2012 10:07, Mike Kimber <> wrote:
>>>> Good on you for trying something different. I cast 100 votes and then
>>>> figured that was enough. If you want my top 5 then they are:
>>>> 1. Chained Views
>>>> 2. Richer Map Reduce
>>>> 3. Simpler Query
>>>> 4. Performance (high update low query/read) i.e. incremental map reduce
>>>> 5. Documentation
>>>> We use CouchDB fro analytic, hence the bias above :-)
>>>> Keep up the good work
>>>> Thanks
>>>> Mike
>>>> -----Original Message-----
>>>> From: Robert Newson []
>>>> Sent: 14 April 2012 18:30
>>>> To:
>>>> Cc:
>>>> Subject: Re: Help shape the future of CouchDB: your voice needed!
>>>> The feedback on the mailing lists, IRC and twitter has been very
>>>> helpful, thanks everyone for the responses!
>>>> I'm going to take this feedback and provide a condensed list of
>>>> features. I will write up each item on our wiki, then we'll reset the
>>>> poll so that more folks can vote knowledgeably on the features. I
>>>> suspect it'll be a couple of hours, so I'll post here when it's up.
>>>> Thanks!
>>>> B.
>>>> On 14 April 2012 17:30, Bob Dionne <> wrote:
>>>>> I kind of agree, though I think voting is neat. I'd like to think most
>>>> of these features are influenced by experiences with users in addition to
>>>> internal refactoring concerns and so forth.
>>>>> It might help for everyone to see the list of features (here's a cleaned
>>>> up version I got from BobN) [1]. As Benoit suggests, we need to
>>>> sort/categorize them first before attaching priorities.
>>>>> One thing we might think of is the areas they might be grouped in, along
>>>> the line of teams as Jan suggested at the summit.
>>>>> I'm happy to maintain this list as we drill down into the specifics,
>>>> summarize email threads, and IRC chats. Some of these, .eg. moving metadata
>>>> out of the docs, could easily require a lot of detailed discussion as they
>>>> hit many areas of the code, so we should flesh out the details.
>>>>> It was great to meet everyone finally, I think we accomplished a whole
>>>> lot. Thanks to Cloudant, Bocoup, and others for hosting, beers, etc.. and
>>>> big thanks to Sam Bisbee and Joan Touzet for detailed notes and general cat
>>>> herding.
>>>>> Bob
>>>>> [1]
>>>>> On Apr 14, 2012, at 11:10 AM, Klaus Trainer wrote:
>>>>>> I know CouchDB's internals to some degree and even contributed a
>>>>>> bits to its codebase a while ago (and still follow its development
>>>>>> some degree). However, I see myself primarily as a CouchDB user.
>>>>>> been using it successfully not only in my own pet projects, but also
>>>>>> together with a small team in a consulting project for a client.
I do
>>>>>> have experience when it comes to explaining CouchDB's ideas, concepts,
>>>>>> and how it can be used in practice to both technical and non-technical
>>>>>> people.
>>>>>> </DISCLAIMER>
>>>>>> My initial reaction to this web page was very positive (hey, great
>>>>>> have a collection of great new features that we can vote upon and
>>>>>> implement!). After voting and having had some sleep on it, I'm pretty
>>>>>> sure that it's not suitable, at least not in this way, though. The
>>>>>> problem that I have with it is that I'm quite convinced that if we
>>>>>> to implement the features corresponding to their score on the results
>>>>>> page (,
>>>> will
>>>>>> either fail executing for some reason, or (the worse case), succeed
>>>>>> have given CouchDB a more catchy list of features instead of having
>>>>>> made a better piece of software. Please let me explain the issues
>>>>>> seem important to me.
>>>>>> The main problem with that survey is that it does neither ask nor
>>>>>> the questions that are actually important if we want to make CouchDB
>>>>>> even better piece of software. I collected three main questions:
>>>>>> 1. What problem, or rather what type of problems does that feature
>>>>>> solve?
>>>>>> 2. What are the implications and tradeoffs for the different types
>>>>>> stakeholders that the feature brings with it?
>>>>>>    - For me as a CouchDB user, how will that feature affect me when
>>>>>> using CouchDB?
>>>>>>    - For me as a third-party developer, how will that feature affect
>>>>>> work on CouchDB modules/plugins/tools?
>>>>>>    - For me as a CouchDB core developer, how will that feature affect
>>>>>> my work on CouchDB?
>>>>>>    - For me as as CouchDB package maintainer, how will that feature
>>>>>> affect my work on packaging/maintaining CouchDB?
>>>>>>    - For me as as Sysadmin / CouchDB operator, how will that feature
>>>>>> affect me on operating CouchDB?
>>>>>> 3. How is or how can an existing problem be solved without having
>>>>>> feature implemented in CouchDB directly? (That is, are there
>>>>>> modules/plugins/tools available that help me solve that problem.
If not,
>>>>>> how difficult would it be to create one?)
>>>>>> Furthermore, I've got one additional question that, although it likely
>>>>>> helps understanding a feature, however is not as important as the
>>>>>> above:
>>>>>> -> What are the reasons that the feature has not already been
>>>>>> implemented?
>>>>>> This question is probably easier to answer when having a list of
>>>>>> potential answers, for instance:
>>>>>> * Only very few users have that issue, and most users will likely
>>>>>> have to deal with it.
>>>>>> * Most users are confronted with that issue at some time, but it's
>>>>>> trivial to solve it without having the feature in CouchDB anyway.
>>>>>> * It's hard to implement because (although feasible) it's just so
>>>>>> work.
>>>>>> * It's hard to implement because its highly complex and very uncertain
>>>>>> if it can be brought into CouchDB anyway.
>>>>>> * Although easy to implement or already implemented, it hasn't been
>>>>>> and/or won't be accepted by the CouchDB core developers for some
>>>>>> On Fri, 2012-04-13 at 20:24 -0400, Joan Touzet wrote:
>>>>>>> Thanks to everyone who participated in the CouchDB summit in
>>>> this
>>>>>>> week! In case you didn't know, the (25 pages!) of meeting minutes
>>>>>>> available for review at .
>>>>>>> Here's where we need YOUR HELP. During the summit, the participants
>>>>>>> identified 38 key features we think are important for CouchDB's
>>>>>>> Please help us RANK these ideas by visiting our All Our Ideas
>>>>>>> All Our Ideas is a free/open source solution for voting based
>>>>>>> pairwise comparison - think Kittenwar - and is super easy to
>>>>>>> Please complete as many comparisons as you can; we'd like all
>>>>>>> feedback we can get. We'd be thrilled if each of you did at least
>>>>>>> comparisons.
>>>>>>> Thanks again for your help in determining the future of Apache

View raw message