Transactional CouchDB (was Re: Current CouchDB state?)

[Wout Mertens <wm...@cisco.com>]

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.