From user-return-3401-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Feb 09 14:37:02 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 6344 invoked from network); 9 Feb 2009 14:37:02 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 9 Feb 2009 14:37:02 -0000 Received: (qmail 9717 invoked by uid 500); 9 Feb 2009 14:36:59 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 9690 invoked by uid 500); 9 Feb 2009 14:36:59 -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 9679 invoked by uid 99); 9 Feb 2009 14:36:59 -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 06:36:59 -0800 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.68.5.17] (HELO relay03.pair.com) (209.68.5.17) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 09 Feb 2009 14:36:51 +0000 Received: (qmail 65275 invoked from network); 9 Feb 2009 14:36:30 -0000 Received: from 96.33.90.152 (HELO ?192.168.1.195?) (96.33.90.152) by relay03.pair.com with SMTP; 9 Feb 2009 14:36:30 -0000 X-pair-Authenticated: 96.33.90.152 Message-Id: From: Damien Katz To: user@couchdb.apache.org In-Reply-To: <5186956f0902090627y1239b12es505ee80b2d6bd248@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 09:36:30 -0500 References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com> <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com> <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com> <5186956f0902090449s76befd76g4cf9ded9f59efc86@mail.gmail.com> <5186956f0902090627y1239b12es505ee80b2d6bd248@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 9, 2009, at 9:27 AM, Mister Donut wrote: >> I'm suspecting here >> that you assume that views are created on demand, based on user- >> input. > > No, I understand. > >> Totally generic object behaviour abstractions >> in SQL need something like 8 tables, there's no way this flies :) > > No, I was talking about the "Stuffing" implementation. All it does is > adding a schema-free field to an existing database? I just don't see > what it has anything to do with CouchDB? > >> How? (Assuming you have a use-case in mind, can you explain that?) > > Again, about the "Stuffing". It doesn't handle the lack of immediate > consistency. This is just what I seem to observe here. Everyone > praises the schema-free and JSON, but noone keeps the *eventual* > consistency in mind? > >> Again, can you wrap that into a concrete example, I don't quite get >> what >> that mini-RDBMS is and how your understanding of replication ties >> into that :) > > You have to deal with the *eventual* consistency in your applications > don't you? And isn't that incredibly hard and expensive? I mean just > think about the end user, when he might put something in CouchDB, but > not immediatly see it, in fact, it might be gone for a very long time. > What interactive application can work with that? Actually that's not true. We aren't using a system like SimpleDB where your changes might not be immediately available in subsequent queries by the same user. Eventually consistency in CouchDB refers to remote replication, where multiple changes that otherwise should be grouped together won't necessary replicate together, and certainly not in one transaction. But eventually they all get there. -Damien > > >> I have another contract about to start for a server app where all the >> data is maintained on the client's desktop, previewed with full >> functionality, and then replicated to an EC2 instance. This can be >> done with traditional databases, but it's trivial with CouchDB, > > Well, this is trivial with all databases? Just import and export. It's > just copying a file. Now imagine two users working on the data. Yes, > you have replication built in, so no data gets lost. But you still > need to figure out all the merging? Hum.