incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mister Donut <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 14:27:28 GMT
> 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?

> 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