Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 17388 invoked from network); 9 Feb 2009 10:59:04 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 10:59:04 -0000 Received: (qmail 59683 invoked by uid 500); 9 Feb 2009 10:58:58 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 59640 invoked by uid 500); 9 Feb 2009 10:58:57 -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 59629 invoked by uid 99); 9 Feb 2009 10:58:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 02:58:57 -0800 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [83.97.50.139] (HELO jan.prima.de) (83.97.50.139) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Feb 2009 10:58:50 +0000 Received: from dahlia.lan (f053003027.adsl.alicedsl.de [::ffff:78.53.3.27]) (AUTH: LOGIN jan, TLS: TLSv1/SSLv3,128bits,AES128-SHA) by jan.prima.de with esmtp; Mon, 09 Feb 2009 10:58:27 +0000 Message-Id: <8AFC9EF9-E6C3-48D4-B627-A20B927F00C4@apache.org> From: Jan Lehnardt To: user@couchdb.apache.org In-Reply-To: <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Re: The Blog Date: Mon, 9 Feb 2009 11:57:53 +0100 References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com> <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org Hi Mister Donout, It be easier to follow your thoughts, if you would take the time to formulate them in complete sentences. Your offensive tone doesn't help either. For pagination, check this mailing list's archives for several solutions. http://mail-archives.apache.org/mod_mbox/couchdb-user/ http://mail-archives.apache.org/mod_mbox/incubator-couchdb-user/ For the book: We're 4 chapters into it, there's more material on the way that answers your questions. In the meantime, we appreciate any constructive criticism on the book's mailing list: http://groups.google.com/group/couchdb-relax For the wiki, grab an account and fix what's unhelpful. Or at least, file a bug report in JIRA so we are aware of any specific issue in the wiki. (Yes, the wiki is not perfect, but it is open for all to edit). https://issues.apache.org/jira/browse/COUCHDB More comments inline. On 9 Feb 2009, at 11:28, Mister Donut wrote: > > I don't think you understand my point. > Yes, I know. Maybe you should re-read. Maybe you should rephrase? Just a suggestion. Communication is two-way. > You still need one lookup for every blog entry on a page. > And there is no way you can ever store the comment count inside the > blog entry. > >> startkey, endkey and limit. > > That sounds so great. But wait. LIMIT. > I know that from SQL. It doesn't scale. > Jumping to page 1234567 of ten million. Please, no. limit is documented to be slow and should not be used to implement paging. That's what startkey and endkey are for and the mailing list archives show you how that is done. > And you cannot, ever, group items based on a variable criteria. > For example in batches of around one hundred. > Which solves pagination. > A view cannot provide that. But again, there is no way you can > "manually" do it. Which is not the only solution to pagination. >> Anything! > > I challenge you. Build me a counter! > No seriously. > > Pick one: > GROUP BY, LIMIT, _rev to fake transactions. Uh. Oh. Hello SQL? > You know something magical that allows you to avoid _rev. See CAP*, RDBMSs pick consistency and availability where CouchDB picks availability and partitionability. * Consistency, Availability, Partitioning, pick two. > So please tell me. CouchDB is not an RDBMS, you need to change your thinking to solve the things that you are accustomed to solve in RDBMS land. It took me quite a while. . If you try to find 1:1 mappings of solutions from the RDBMS world to CouchDB, you must conclude that CouchDB sucks. But that doesn't mean that CouchDB sucks. I hope we can provide you with enough information about how to do things in CouchDB land. Thanks for asking hard questions, would be great if we could keep this dialogue going. Cheers Jan -- > What exactly can I use CouchDB for that uses its strengths, > and not weaknesses? I am honestly not trying to make a fool of anyone. > The CouchDB book seems only to justify the design choices. > The Wiki is completely unhelpful. > Every time it gets interesting. > http://wiki.apache.org/couchdb/How_to_implement_tagging > It stops. That second article, that would certainly enlighten me. > Yes, how, would you go about implementing that? > > I don't see how you can make it work but by using an awful lot of > merging logic. > Isn't that why you use a RDBMS in the first place? > >> It's already there. > > You're right, I missed that one. It's even more scary.