On Wed, Jan 28, 2009 at 11:40:18AM +0100, Jan Lehnardt wrote:
>> BTW, I do think the atomic nature of bulk_docs is useful and should be
>> kept,
>> as it's the only way to get "transaction" semantics at the moment.
>
> We won't be able to guarantee transactions in a multi-node setup.
This is true - although I presume you mean that the transaction can succeed
on one node, but will then cause a conflict upon replication. If so, I'd say
this is the case with single document updates too (but maybe I have
misunderstood).
Replication conflict resolution is something which I don't have a handle on
yet, I'm afraid, and doesn't seem to be well documented. (*)
Also: is there some guidance as to how to write applications in the absence
of transactions? Take traditional double-entry accounts as an example.
Should we create a single document for each transaction, and use a view to
get the balance of each account? e.g.
{"amount": ...
"credit_ac": [account_name, accounting_period]
"debit_ac": [account_name, accounting_period]}
So a view will give you [account_name, accounting_period] => balance
Replication conflict resolution is avoided simply on the basis that
documents never change, they are only created.
Anyway, have I got the right sort of idea here? IANAA, and I don't think
this system looks very "failsafe", in the sense that if a transaction were
to be lost for any reason, the whole system would still remain in balance so
it would be very hard to detect.
Regards,
Brian.
(*) I can see that replication can result in a document with conflicts
marked; but how is it resolved? Is the conflict marked as resolved as soon
as any client reads the document and writes a new revision?
If so, this means that every time you make an update to a document, you must
first check to see if it is in conflict, and resolve the conflict before
proceeding. Is that correct?
