Also... Jens... You said couchbase doesn't have MVCC ? All docs say That it
uses couchDB MVCC append only under the good on a single node... Could you
elaborate a tad on what you mean by doesn't have MVCC?... Also for the
couchDB advocates...I think discussions about this are incredibly helpful
for all parties involved..
On Mar 26, 2014 2:58 PM, "Stanley Iriele" <[email protected]> wrote:

> Thanks again Jens for the reply... Couchbase has documentation on
> this...and gobs of marketing... But bigcouch does not...
>
> In bigcouch...all nodes can handle every request... But let's say a node
> cannot reach the nodes that have a key..like node A knows it needs to read
> from nodes B and C but cannot reach them.... But has a copy of the data
> locally but was given r=2 for consent read... What does bigcouch do?
>
> Potentially return stale data?.. Throw an error?....
>
> I know that bigcouch is based on the dynamo white paper... But so is
> Cassandra...and riak and you cab at least find out the answers to these
> questions with a little googling. Again I'm eternally grateful for the
> responses I'm getting I just wish there more docs....like the couchDB docs
> page that even has a CAP theorem chart..(which is freaking awesome)..
> On Mar 26, 2014 12:24 PM, "Jens Alfke" <[email protected]> wrote:
>
>>
>> On Mar 26, 2014, at 9:31 AM, Stanley Iriele <[email protected]> wrote:
>>
>> > Why would you say that couchbase scales better?...
>>
>> That's getting way off-topic for this list, but http://couchbase.com has
>> a bunch of marketing materials and white papers and such, and we have sales
>> engineers you can talk to if you really want to dive into it. But as I
>> said, Couchbase Server and BigCouch are very different.
>>
>> > And does bigcouch ever return conflicts to the user? How is the "which
>> write won" problem solved?
>>
>> AFAIK BigCouch's document/revision/conflict model is identical to
>> CouchDBs. MVCC, revision IDs, revision trees, conflicts represented as
>> branched trees, conflict resolution by deleting unwanted branches, etc.
>>
>> --Jens
>
>

Reply via email to