Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <65903643-CEEE-4889-A25C-06D5CA66E70D@apache.org>
From: Jan Lehnardt <jan@apache.org>
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 15:43:59 +0100
References: <5186956f0902082052m43546a8dmb6d9a3ebf9685034@mail.gmail.com>
 <5186956f0902090228p5a6db266l764fde4c82b571d0@mail.gmail.com>
 <5186956f0902090338i2829df1erebaa24a4feea7e06@mail.gmail.com>
 <5186956f0902090449s76befd76g4cf9ded9f59efc86@mail.gmail.com>
 <5186956f0902090627y1239b12es505ee80b2d6bd248@mail.gmail.com>


On 9 Feb 2009, at 15:27, Mister Donut wrote:
> 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?

Stuffing adds a hash to an AR-model that gets stored into CouchDB
when the rest of the model is stored in whatever RDBMS you use.


>> 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?

The use-case here is the single node. A single node is consistent,
just like an RDBMS. You don't have to use CouchDB in the multi-node
configuration. You can just use REST & JSON of CouchDB without
ever needing to thing about eventual consistency.


>> 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?

Yes, you need to make a trade-off on "immediately". On the local node
the users sees his changes immediately, but potentially not on a remote
node due to network partition. If your application is remote only and  
you
have a multi-node cluster where the master the user is writing to dies
before his changes got replicated, he might see "inconsistent" data, but
in that case, the setting could be cached on the application- or user- 
end
or the GUI could inform the user that his setting, despite immediate
success message, couldn't store the setting permanently. This is an
edge case though. You can also make single cluster nodes highly  
available
and write to two or three servers with any write and only report success
if all report success. This has other implications though. Again,  
trade-offs.


>> 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.

Plus locking the DB in the meantime. CouchDB replication is live.


> 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.

Merging is application dependent and can be rarely solved generically.
We've been talking about leaving merging to a user-specifiable function
and potentially shipping with a set of functions for common cases. E.g.
if "older" entries always lose and all docs have a timestamp field,
automatic resolution of conflicts are possible. Or the user-specified
merge function could determine that only different fields in a doc were
changed an auto-merge the two revisions. But now work has been
made on that end. As I said in the last mail, we're still building  
this thing.
Plus: Both things can be done in application-land as well.

(Aside, patches welcome :)

Cheers
Jan
--