couchdb-dev mailing list archives

On Feb 7, 2009, at 5:08 PM, Geir Magnusson Jr. wrote:
>
> On Feb 7, 2009, at 11:22 AM, Damien Katz wrote:
>
>>
>> On Feb 7, 2009, at 11:02 AM, Geir Magnusson Jr. wrote:
>>
>>> Thanks for the info. Is there a third mode possible? Namely all
>>> or nothing with conflict check, with the understanimg that the
>>> conflict guarantee is only at commit, and all bets are off after
>>> that when replicated?
>>>
>>
>> That's what we currently have. It's possible to keep supporting it,
>> but it doesn't work with any of CouchDB's distributed features.
>> It's only appropriate for a single node instance, even a hot
>> standby slave will have inconsistent states.
>
> Sure... Assuming we're defining things the same way, I think that
> the existing mode still might be useful - I could consider a node to
> be the "reference master" for my data (or a subset) and vector all
> writes there with whatever consistency promises I get from a single
> node, and then everyone else will be eventually consistent, and I'd
> know that the eventually consistent nodes have a transactionally
> consistent data set?
>
> I realize I may not attach the same meaning to concepts, but can you
> get a sense of what I'm saying?
>
So a single master node that always in a valid state, inter-document
wise, but slaves nodes are in an unknown inter-document state (could
be a valid state, could be a inconsistent, transitional state).
Unfortunately it can't be used for failover purposes as the slaves
nodes might be in inconsistent inter-document states. And if the
readers need to read dbs in a consistent state, then it doesn't work
for read-only slaves either.
I think this works in situations where you have only a single machine
(no replication, no failover), or your app can have read only slaves
nodes where readers don't care about db consistency (but still no
failover). I'm not sure that fits many real world use cases.
-Damien