From user-return-20531-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Thu Apr 19 11:26:52 2012 Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D0EE39D38 for ; Thu, 19 Apr 2012 11:26:52 +0000 (UTC) Received: (qmail 76902 invoked by uid 500); 19 Apr 2012 11:26:51 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 76857 invoked by uid 500); 19 Apr 2012 11:26:51 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 76846 invoked by uid 99); 19 Apr 2012 11:26:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 19 Apr 2012 11:26:51 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of dionne@dionne-associates.com designates 67.222.54.6 as permitted sender) Received: from [67.222.54.6] (HELO oproxy6-pub.bluehost.com) (67.222.54.6) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 19 Apr 2012 11:26:42 +0000 Received: (qmail 579 invoked by uid 0); 19 Apr 2012 11:26:20 -0000 Received: from unknown (HELO host183.hostmonster.com) (74.220.207.183) by cpoproxy3.bluehost.com with SMTP; 19 Apr 2012 11:26:19 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dionne-associates.com; s=default; h=To:References:Message-Id:Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version:Content-Type; bh=tHRhVCAio+Ac7KuT2kxEY9DkDK2Pxt6AxBa3HoFmubE=; b=ZqrtjL0oZcli0Xkg6SEJO+r2tcFTKBHuxKltwYjGgjYCsjJiRJbYckhv8BqlFzI2n7WmG56jOQxj16ZAX+7sh5QfD+T4xViTs1r+rekaQST4Brr60U0QUPhe6BTwHhbc; Received: from adsl-99-103-111-5.dsl.wlfrct.sbcglobal.net ([99.103.111.5] helo=[192.168.1.115]) by host183.hostmonster.com with esmtpa (Exim 4.76) (envelope-from ) id 1SKpVB-0004d9-W7 for user@couchdb.apache.org; Thu, 19 Apr 2012 05:26:19 -0600 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1257) Subject: Re: Help shape the future of CouchDB: your voice needed! From: Bob Dionne In-Reply-To: Date: Thu, 19 Apr 2012 07:26:15 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29D72155-D8F2-4F0B-AE7F-DA024F8CE861@dionne-associates.com> References: <20120414002434.GA22219@atypical.net> <1334416226.2951.1.camel@devil> <91DAAC41-2AE8-44F0-88A4-FFFDC927E277@dionne-associates.com> To: user@couchdb.apache.org X-Mailer: Apple Mail (2.1257) X-Identified-User: {:host183.hostmonster.com:dionne@dionne-associates.com:} {sentby:smtp auth 99.103.111.5 authed with dionne@dionne-associates.com} Mike, 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.=20 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.=20 Let us know what you think after you've played around with MR. Bob On Apr 19, 2012, at 6:51 AM, Mike Kimber wrote: > Robert, >=20 > 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. >=20 > 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. >=20 > Mike=20 >=20 > -----Original Message----- > From: Robert Newson [mailto:rnewson@apache.org]=20 > Sent: 18 April 2012 14:11 > To: user@couchdb.apache.org > Subject: Re: Help shape the future of CouchDB: your voice needed! >=20 > 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? >=20 > B. >=20 > On 18 April 2012 14:06, Mike Kimber wrote: >> Ok thanks. Is there any details on what "Simpler Querying" on the = roadmap list might mean? >>=20 >> Mike >>=20 >> -----Original Message----- >> From: Robert Newson [mailto:rnewson@apache.org] >> Sent: 18 April 2012 14:02 >> To: user@couchdb.apache.org >> Subject: Re: Help shape the future of CouchDB: your voice needed! >>=20 >> I don't see UNQL appearing on CouchDB's roadmap. >>=20 >> B. >>=20 >> On 18 April 2012 13:44, Mike Kimber wrote: >>> One thing I did not see on the roadmap was UNQL: >>>=20 >>> Is this covered by Simpler Querying? >>> Is UNQL still something that interests Couchdb and if so what sort = time frame are we talking? >>>=20 >>> Thanks >>>=20 >>> Mike >>>=20 >>>=20 >>> -----Original Message----- >>> From: Alon Keren [mailto:alon.keren@gmail.com] >>> Sent: 16 April 2012 21:28 >>> To: user@couchdb.apache.org >>> Subject: Re: Help shape the future of CouchDB: your voice needed! >>>=20 >>> Thank you guys for making this poll, and for publishing the minutes = and >>> audio. >>>=20 >>> 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. >>>=20 >>> Alon >>>=20 >>> On 16 April 2012 10:07, Mike Kimber wrote: >>>=20 >>>> 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: >>>>=20 >>>> 1. Chained Views >>>> 2. Richer Map Reduce >>>> 3. Simpler Query >>>> 4. Performance (high update low query/read) i.e. incremental map = reduce >>>> 5. Documentation >>>>=20 >>>> We use CouchDB fro analytic, hence the bias above :-) >>>>=20 >>>> Keep up the good work >>>>=20 >>>> Thanks >>>>=20 >>>> Mike >>>>=20 >>>> -----Original Message----- >>>> From: Robert Newson [mailto:rnewson@apache.org] >>>> Sent: 14 April 2012 18:30 >>>> To: dev@couchdb.apache.org >>>> Cc: user@couchdb.apache.org >>>> Subject: Re: Help shape the future of CouchDB: your voice needed! >>>>=20 >>>> The feedback on the mailing lists, IRC and twitter has been very >>>> helpful, thanks everyone for the responses! >>>>=20 >>>> 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. >>>>=20 >>>> Thanks! >>>> B. >>>>=20 >>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Bob >>>>>=20 >>>>> [1] >>>> = https://github.com/bdionne/couchdb/blob/master/feature-list-from-summit.md= >>>>>=20 >>>>>=20 >>>>> On Apr 14, 2012, at 11:10 AM, Klaus Trainer wrote: >>>>>=20 >>>>>> >>>>>> 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. >>>>>> >>>>>>=20 >>>>>>=20 >>>>>> 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=3Dtrue), = 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. >>>>>>=20 >>>>>>=20 >>>>>> 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: >>>>>>=20 >>>>>> 1. What problem, or rather what type of problems does that = feature >>>>>> solve? >>>>>>=20 >>>>>> 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? >>>>>>=20 >>>>>> 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?) >>>>>>=20 >>>>>>=20 >>>>>> Furthermore, I've got one additional question that, although it = likely >>>>>> helps understanding a feature, however is not as important as the = three >>>>>> above: >>>>>>=20 >>>>>> -> What are the reasons that the feature has not already been >>>>>> implemented? >>>>>>=20 >>>>>> This question is probably easier to answer when having a list of >>>>>> potential answers, for instance: >>>>>>=20 >>>>>> * 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. >>>>>>=20 >>>>>>=20 >>>>>> 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 . >>>>>>>=20 >>>>>>> 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: >>>>>>>=20 >>>>>>> http://www.allourideas.org/couchdb2012/ >>>>>>>=20 >>>>>>> All Our Ideas is a free/open source solution for voting based on >>>>>>> pairwise comparison - think Kittenwar - and is super easy to = use. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Thanks again for your help in determining the future of Apache = CouchDB! >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20