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
