couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: The Blog
Date Mon, 09 Feb 2009 14:56:13 GMT

On 9 Feb 2009, at 15:51, Adam Petty wrote:

> Mr. Donut, Jan,Damien, others in the thread,
> Just want to say thank you.

Heh, thanks.

> I'm being completely serious here.  I have to agree that in the  
> beginning I
> sensed hostility from Mr. Donut - but he was hitting on many  
> questions I
> knew there were answers for and after a few minutes could  
> conceptualise -
> but never had at the tip of my tongue to give to the other RDBMS  
> guys in my
> office when they rightfully grill me about using CouchDB for the  
> next gen.
> production environment.
> Could this thread be added to the wiki - with only minor editing for  
> length
> - maybe as "a RDBMS vs couch 'Discussion' ?"  or something  
> similar?"...

Feel free to collect a summary put it into the wiki :)


> Mr. Donut - please continue.....
> And Damien - I might be wrong but I believe the consistency Donut was
> referring to the was maybe changing the type of data in a field on  
> the back
> end midway through the app lifecycle - or maybe through a bug in the
> application.  Or conversly adding a field - which also would then be  
> handled
> through the business layer.  I would guess this would include  
> refining a
> view to include it if it needed to be searched on - and then  
> correcting the
> business layer to accomodate for either the new view - or the new  
> key in the
> view.
> I was thinking this was a benefit but it did take a some  
> redefinition of the
> scope of a database for me to understand from the getgo. Also, it  
> seems to
> simplify the schema into truely being part of the business logic  
> layer of an
> applicaiton.  If the data needs an application to get to the  
> database -
> finally we can enforce that data integrity in only one place - but,  
> Donut if
> this isn't accurate, please reframe.
> (and I see Jan has answered in a similar and yet much more eloquent  
> way
> while I was typing this...)
> -- Adam
> On Mon, 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?
>>> 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