I can speak only for myself but I've been SQL syntax free for years. I even got my sense of smell back.
B. On 19 April 2012 11:51, Mike Kimber <[email protected]> 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 comment. > > However one generic NoSQL observation i.e. no just Couchdb is that despite > NoSQL being well "No SQL", Google with Dremel ( > http://research.google.com/pubs/pub36632.html ) 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 [mailto:[email protected]] > Sent: 18 April 2012 14:11 > To: [email protected] > 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 <[email protected]> wrote: >> Ok thanks. Is there any details on what "Simpler Querying" on the roadmap >> list might mean? >> >> Mike >> >> -----Original Message----- >> From: Robert Newson [mailto:[email protected]] >> Sent: 18 April 2012 14:02 >> To: [email protected] >> 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 <[email protected]> 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 [mailto:[email protected]] >>> Sent: 16 April 2012 21:28 >>> To: [email protected] >>> 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 <[email protected]> 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 [mailto:[email protected]] >>>> Sent: 14 April 2012 18:30 >>>> To: [email protected] >>>> Cc: [email protected] >>>> 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 <[email protected]> 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 a >>>> big thanks to Sam Bisbee and Joan Touzet for detailed notes and general cat >>>> herding. >>>> > >>>> > Bob >>>> > >>>> > [1] >>>> https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.md >>>> > >>>> > >>>> > On Apr 14, 2012, at 11:10 AM, Klaus Trainer wrote: >>>> > >>>> >> <DISCLAIMER> >>>> >> I know CouchDB's internals to some degree and even contributed a few >>>> >> bits to its codebase a while ago (and still follow its development to >>>> >> some degree). However, I see myself primarily as a CouchDB user. I've >>>> >> 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 to >>>> >> 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 main >>>> >> problem that I have with it is that I'm quite convinced that if we try >>>> >> to implement the features corresponding to their score on the results >>>> >> page (http://www.allourideas.org/couchdb2012/results?more=true), we >>>> will >>>> >> either fail executing for some reason, or (the worse case), succeed and >>>> >> have given CouchDB a more catchy list of features instead of having it >>>> >> made a better piece of software. Please let me explain the issues that >>>> >> seem important to me. >>>> >> >>>> >> >>>> >> The main problem with that survey is that it does neither ask nor answer >>>> >> the questions that are actually important if we want to make CouchDB an >>>> >> 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 of >>>> >> stakeholders that the feature brings with it? >>>> >> - For me as a CouchDB user, how will that feature affect me when I'm >>>> >> using CouchDB? >>>> >> - For me as a third-party developer, how will that feature affect my >>>> >> 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 the >>>> >> 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 three >>>> >> 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 never >>>> >> have to deal with it. >>>> >> * Most users are confronted with that issue at some time, but it's so >>>> >> trivial to solve it without having the feature in CouchDB anyway. >>>> >> * It's hard to implement because (although feasible) it's just so much >>>> >> 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 reason. >>>> >> >>>> >> >>>> >> On Fri, 2012-04-13 at 20:24 -0400, Joan Touzet wrote: >>>> >>> Thanks to everyone who participated in the CouchDB summit in Boston >>>> this >>>> >>> week! In case you didn't know, the (25 pages!) of meeting minutes are >>>> >>> available for review at http://s.apache.org/ndI . >>>> >>> >>>> >>> Here's where we need YOUR HELP. During the summit, the participants >>>> >>> identified 38 key features we think are important for CouchDB's future. >>>> >>> Please help us RANK these ideas by visiting our All Our Ideas page: >>>> >>> >>>> >>> http://www.allourideas.org/couchdb2012/ >>>> >>> >>>> >>> All Our Ideas is a free/open source solution for voting based on >>>> >>> pairwise comparison - think Kittenwar - and is super easy to use. >>>> >>> >>>> >>> Please complete as many comparisons as you can; we'd like all the >>>> >>> feedback we can get. We'd be thrilled if each of you did at least 100 >>>> >>> comparisons. >>>> >>> >>>> >>> Thanks again for your help in determining the future of Apache CouchDB! >>>> >>> >>>> >> >>>> > >>>>
