couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damien Katz <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 14:36:30 GMT

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.


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

View raw message