On Feb 7, 2009, at 6:05 PM, Damien Katz wrote:
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 understand - my POV is that they'd eventually get into a consistent
state assuming the master doesn't go down.
If the master goes down, they could, but that's what I think I'd get
with what you are proposing nayway.
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.
But how is the end result different from what you are proposing to
change to?
geir
-Damien
