Replying to snippet:
On Jan 28, 2009, at 12:55 PM, Brian Candler wrote:
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.
It seems to me that to properly implement double-entry accounts, you
would in fact use two separate databases. Note however that double-
entry was invented to detect human mistakes. With computers you would
probably want to detect inconsistencies arising from computer
problems; this is probably different from what humans produce.
So in this case you probably want to write somewhere in a very trusted
system "I'm about to perform this transaction", then perform the
transaction (two records, debit and credit, one for each account?) and
finally put in the trusted system "I did the transaction".
A lot like log-structured filesystems, in fact. Of course, I never
coded anything like that so there are probably better ways.
Wout.
