Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 7262 invoked from network); 2 Feb 2009 18:15:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 2 Feb 2009 18:15:36 -0000 Received: (qmail 14874 invoked by uid 500); 2 Feb 2009 18:15:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 14847 invoked by uid 500); 2 Feb 2009 18:15:34 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 14836 invoked by uid 99); 2 Feb 2009 18:15:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Feb 2009 10:15:34 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of wmertens@cisco.com designates 144.254.15.119 as permitted sender) Received: from [144.254.15.119] (HELO av-tac-bru.cisco.com) (144.254.15.119) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Feb 2009 18:15:27 +0000 X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost [127.0.0.1]) by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n12IF5b20456 for ; Mon, 2 Feb 2009 19:15:06 +0100 (CET) Received: from ams3-vpn-dhcp8144.cisco.com (ams3-vpn-dhcp8144.cisco.com [10.61.95.207]) by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id n12IF5t22011 for ; Mon, 2 Feb 2009 19:15:05 +0100 (CET) Message-Id: <9393F5EC-FCFD-4FCF-AC99-D3D696A54075@cisco.com> From: Wout Mertens To: user@couchdb.apache.org In-Reply-To: <20090128115540.GA9910@uk.tiscali.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Subject: Transactional CouchDB (was Re: Current CouchDB state?) Date: Mon, 2 Feb 2009 19:15:03 +0100 References: <4B2C1E46-F592-4924-B2DB-E58668C9C0F7@apache.org> <20090127212253.GA15826@uk.tiscali.com> <20090128090520.GB7338@uk.tiscali.com> <20090128092104.GA7997@uk.tiscali.com> <20090128103101.GA8915@uk.tiscali.com> <81A8C1E7-85AA-403A-9AAB-AA8D7BB3371C@apache.org> <20090128115540.GA9910@uk.tiscali.com> X-Mailer: Apple Mail (2.930.3) X-Virus-Checked: Checked by ClamAV on apache.org 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.